OSDev.org

I just figured that on x86 it seems to be possible to have some of the interrupt vectors point to CPL3 segments. So in theory, CPU exceptions that are safe to handle in userspace could be handled without trapping into kernel at all.

Now, I'm wondering whether this has been used, and whether there are some things to watch out. Basicly, what I'm thinking would be to have piece of the kernel code readable to userspace and trap into that code keeping CPL as 3, then dispatch to the real user-settable exception handler from there. The only real purpose of having predefined userspace "kernel" code would be to avoid tweaking IDT on process switches, but one could ofcourse have a pre-process IDT too, since IDT's referenced with a linear address. Either method would work.

At least exceptions 0 (divide), 4 (overflow), 5 (bound), 16 (math), 17 (align check) and 19 (simd) could be dispatched safely in userspace.

Additionally, if we had debugger support in userspace (and communicated with debugger using IPC, or self debugged), we could have 1 (debug), 3 (break) and 6 (inv op) in userspace just as well.

Of the remaining exceptions 2 (NMI), 8 (double fault) and 18 (machine check) are probably fatal. 10 (tss), 11 (segment not present) and 12 (stack) normally won't happen with your typical no-segments setup. Copro overrun 9 won't happen with modern processors.

So 7 (fpu not available), 13 (general protection) and 14 (page fault, see below) seem like the only ones that kernel should actually do something about.

What would be avoided would be an extra stack switch and moving data from kernel to userspace when there is an userspace signal handler. Additionally, the userspace "stub" could skip reloading CS on return, which could save a few more cycles. (?)
Anyway, the main motivation would be that more of the exception handling could be directly accounted to the faulting process.

Page faults unfortunately can't be handled in userspace even in self-paging case, because the trap must disable interrupts and kernel read CR2 so that we can get the address. I wonder why the page isn't pushed with the error-code (there would be space for it just fine and one usually doesn't need to whole address).

Now, am I missing something?

Hi,

mystran wrote:Now, am I missing something?

I can't think of anything wrong with any of this .


Cheers,

Brendan

What would happen if the kernel divided by zero? What if you implement a kernel debugger and need int 1 and 3 to go directly to kernel space?

Although this is a good idea, I think that you generally want the least complicated path for exceptions that occur in the kernel so that there is less opportunity for something to go wrong.

Besides these arguments, which all can be overcome, I think you have a good idea.

Good luck,
Mike

Kernel debugger is a valid concern, but I don't think I'll be having divide-by-zero in kernel.

I was thinking of having the (almost) minimal possible kernel, and assuming it can be written in such a way that it simply does not cause any exceptions itself, except possibly page faults, which need to be handled by kernel in any case.

Guarding agaist kernel bugs is ofcourse a nice thing to have though. Other than that, I don't see why the kernel would need to cause any exceptions.

mystran wrote: I just figured that on x86 it seems to be possible to have some of the interrupt vectors point to CPL3 segments. So in theory, CPU exceptions that are safe to handle in userspace could be handled without trapping into kernel at all.

Hm. Did you actually tested it so far ? i mean putting a code selector with DPL=3 in an exception descriptor ?

Afaik, i read somewhere in intel manuals that having DPL>0 in an IRQ descriptor was not tolerated. Maybe things are different for exceptions but i'd be careful if i were you.

No, I didn't test it yet, but...

First, IRQ != Exception.
Second, you remember slightly wrong.

To quote The IA-32 manual volume 3, section 5.12.1.1:

The privilege-level protection for exception- and interrupt-handler procedures is similar to that used for ordinary procedure calls when called through a call gate [...]. The processor does not permit transfers of execution to an exception- or interrupt-handler procedure in a less privileged code segment (numerically greater privilege level) than the CPL.

An attempt to violate this rule results in a general-protection exception (#GP). [...]

It then goes on to explain that since there is no RPL, the RPL is not checked, and that CPL>DPL only prevents software interrupts, not hardware interrupts (obviously this must be so).

Futher, it goes on to explain that because interrupts and exceptions can happen at any time, one must either live with the #GP, place the handlers in ring0, or put it into a "conforming code segment".

So yes, for all normal purposes IRQ's must be handled with a ring0 handler (unless you never enable interrupts in ring0). But exception handlers can be in ring3 as long as you're either happy with a #GP for kernel exceptions, or never cause those exceptions in kernel at all. Since page faults are the only ones that I can think of being useful in my kernel, and those need a ring0 handler anyway, I don't really see this as a problem. Since you get a #GP then anyway, you can safely panic if necessary.

I'd futher guess that if you try to put #GP handler in ring3, and trigger a #GP from kernel, you get a double fault, and if that's in ring3 as well, then you get a tripple fault. But nobody's probably going to have #GP (or double fault) in ring3.

But indeed, I'm just speculating. I haven't tried yet.

hmm ... thanks for the refresh. Well, if it's actually the case, then yes, we could have exceptions and even software interrupts redirected to usermode code directly. The second one is especially neat since it will allow (for instance) very cheap emulation of -say- linux system calls within the emulating process

Interesting.

So if I'm reading this right then so long as the scheduler is in a conforming segment that segment could be ring 3 and still receive IRQs from the timer. Or have I missed something?

Curufir wrote: So if I'm reading this right then so long as the scheduler is in a conforming segment that segment could be ring 3 and still receive IRQs from the timer. Or have I missed something?

i don't exactly see how you would benefit of a scheduler at ring 3 ... nor why you'd like to receive timer interrupts while being within the scheduler ... that will usually trash the whole thing...

Pype.Clicker wrote: i don't exactly see how you would benefit of a scheduler at ring 3 ...

Basically me thinking aloud wrt the paging idea I proposed a few days back. If the scheduler could run in ring 3 then it might be possible to do away with the ring transition for each switch between processes. IIRC the internal actions of the processor on receiving an IRQ don't automatically include a ring transition.

nor why you'd like to receive timer interrupts while being within the scheduler ... that will usually trash the whole thing...

My fault for a bad explanation. Should have said something like: so long as the scheduler is in a conforming segment that segment could be ring 3 and still be the target of the timer IRQ's IDT entry.