Re: Privilege Levels Below User

On Tue, 11 Jun 2024 10:03:36 +0200
Terje Mathisen <terje.mathisen@tmsw.no> wrote:

 
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.
 

I think, even the very first IBM PC had one Intel 8259 PIC. PC/XT had it
for sure. So, priorities were here. How useful, is another question.

One of the problems was that right from the beginning IBM engineers
ignored Intel's recommendations to wire external interrupts to IRQ
numbers 32 or higher. They thought that they know better. Of course,
they didn't.

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.
>

PC/AT had two 8259 PICs connected as master and slave. So, more
priority levels at cost of less simple programming.
Now, 80286 CPU had ALOT of interrupt processing features non-heard of by
earlier CPUs, but those were available only in protected mode, so
that's probably not what you had in mind above.

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
>

I think, Eric more than a little exaggerates about the level of
complexity of end-of-interrupt processing needed in common case.
May be, the code is long, but absolute majority of it is executed very
rarely, if at all.