Path: ...!2.eu.feeder.erje.net!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Terje Mathisen <terje.mathisen@tmsw.no>
Newsgroups: comp.arch
Subject: Re: Privilege Levels Below User
Date: Tue, 11 Jun 2024 10:03:36 +0200
Organization: A noiseless patient Spider
Lines: 84
Message-ID: <v490co$v1vj$1@dont-email.me>
References: <jai66jd4ih4ejmek0abnl4gvg5td4obsqg@4ax.com>
 <Z9I8O.13$2JEf.11@fx14.iad> <5h%8O.4327$wDZ.776@fx48.iad>
 <1316e4baa439de908666e38c39cd8c79@www.novabbs.org> <ywE9O.33$46t.1@fx46.iad>
 <v47avm$ht65$1@dont-email.me> <nFH9O.398$jzkf.157@fx06.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 11 Jun 2024 10:03:37 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="19146e3c187a11f3501a0d7b8685ceb1";
	logging-data="1017843"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/9+3Jf+Ti8oLFtCfz3/LGnSR5HJSHgRidWE/4RNMVwCA=="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Firefox/91.0 SeaMonkey/2.53.18.2
Cancel-Lock: sha1:DriiV9k9hGainR5KO3w9vNIi0iU=
In-Reply-To: <nFH9O.398$jzkf.157@fx06.iad>
Bytes: 5160

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"