Re: Privilege Levels Below User

EricP wrote:

Terje Mathisen wrote:

EricP wrote:
[snip]

Many processors automatically disable interrupts on trap because it
greatly simplifies the race conditions in their prologue and epilogue.
x86 did not disable interrupts on exceptions but x64 allows it as an option.

>
I have written a lot of x86 interrupt handlers, these chips did very much disable all interrupts when transferring control to my handler.
>
The typical approach was to do the minimum work possible to save whatever HW buffer/data needed saving, before executing a STI (SeT Interrupt enable bit?) and then do anything else that had to be done while still in the primary handler.
>
IRET restored flags, IP and CS, transferring control back to whatever was running when the hw interrupt happened.
>
Terje

 Yes, for x86/x64 external interrupts it raises the IRQ priority to that of
the requesting device, masking further interrupts of the same or lower IRQ
priority. Or you can explicitly disable all maskable interrupts.

I guess my vintage is showing! When I wrote HW interrupt handlers, none of this applied so it was a much simpler world.
Initially there was no real priority in use because my handler would start with IRQ disabled, I would poll/read the single byte serial port buffer, then clear a hardware interrupt flag and then simply IRET.
A little later (286?) it became possible to selectively re-enable only those interrupts that had a higher priority, so I would do that when my most critical work was done.
Even later the serial port chip was replaced with a far better one which had 16-byte IO buffers and programmable interrupt levels. AFAIR I would typically set it to signal when the buffer was half full, but 14 of 16 was also possible?

 However for exceptions and NMI x86 does not mask interrupts so it is
possible for, say, a page fault or INT instruction to trap to the OS,
saving a frame on the stack, and just then an external interrupt to
arrive, saving another frame.
 On the return from the interrupt or exception (we want a common return
code path) we need to know if this is a First Level Exception/Interrupt.
If not, we take the simple path and just REI Return Exception or Interrupt.
If it is a FLEI then we need to check for deferred work and jump into
the OS. Also it we are returning to User mode we may need to check
for things like thread APCs/signals that arrived while we were away.
 On x86 there is also the difference between stack frame shape
depending on whether the prior mode was User or Super.
On x64 they fixed this so they are the same shape.
 Then there is the difference between SYSCALL/SYSRET vs SYSENTER/SYSEXIT,
and that one did not set the system stack pointer on entry,
which leaves a security hole if an interrupt arrives just before
you can patch it.
 And there was the NMI race condition bug, details of which I have
forgotten but was again something to do with the system stack not
being set correctly after switching to Super and then an NMI arrives
which does not set the stack because the prior mode was already Super.
 Its not that these are not handleable, its that it takes literally
hundreds of instructions in the x86/x64 prologues and epilogues closing
each of these holes and idiosyncrasies. And that's on top of the already
large clocks cost for the IDT and call gates, and REI instructions.
 *None* of this should be necessary.
Even the pipeline drain on mode switch should often be avoidable.
 

Ouch! Glad I got out of the IRQ handler business before 1990.
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"