DPL

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
Ozz

DPL

Post by Ozz »

I read before that you, talking about interrupts, use the DPL to tell the computer which priviledge levels the interrupts could be called from. But spose I set the priviledge level of interrupt 0x20 to 0, and then run a program in ring 3.

Then I cant use the "INT 0x20" in my program. But if this IRQ fires (or if I do the same thing with an exception), will the handler still be fired? Does DPL = 0 just prevent the application from using the INT-instruction? If not, what happends if an exception occurs but the handler can only be reached from ring 0?
bkilgore

Re:DPL

Post by bkilgore »

Hard interrupts (generated by hardware, versus soft interrupts generated with a call to INTn), and exceptions will always call the interrupt handler regardless of the DPL. The DPL is only used to prevent explicit software interrupts from being able to execute the interrupt handler.
Ozz

Re:DPL

Post by Ozz »

So u mean the only reason for setting DPL = 0 is to prevent user application from calling software interrupts / faking an IRQ-interrupt/exception?
bkilgore

Re:DPL

Post by bkilgore »

Yeah, except they can't "fake call" an exception. Once you remap your PIC, if they say INT 0, it calls the interrupt to wherever that was redirected, not your exception 0 handler. The only way for an exception handler to be called is if an exception is generated. So really just to prevent them from calling your IRQ handlers, and only letting them call interrupts that you want them to use for communicating with your kernel (i.e. syscall interrupt, if thats the method you choose to do process->kernel calls)
Dreamsmith

Re:DPL

Post by Dreamsmith »

bkilgore wrote:Yeah, except they can't "fake call" an exception. Once you remap your PIC, if they say INT 0, it calls the interrupt to wherever that was redirected, not your exception 0 handler. The only way for an exception handler to be called is if an exception is generated. So really just to prevent them from calling your IRQ handlers, and only letting them call interrupts that you want them to use for communicating with your kernel (i.e. syscall interrupt, if thats the method you choose to do process->kernel calls)
The above appears to be horribly confused. Let me clarify a couple of things.

First, remapping your PIC has no affect at all whatsoever on how exceptions are handled, nor on how software interrupts (INT x) are handled. It only affects which IDT vectors are used when hardware interrupts are generated. INT 3, for example, always calls your breakpoint handler, even if you've told the PIC to redirect IRQ 3 to your COM port handler. Nothing you do to the PIC ever has any affect at all on how software interrupts are handled.

Secondly, it's most certainly not true that "the only way for an exception handler to be called is if an exception is generated". Exception handlers can be called numerous ways: by generating the exception, by generating a software interrupt, by CALLing or JMPing to its entry point, by pushing its entry point on stack and returning through it, etc. Protection must be used to prevent most of these from working from user space (in which case they'll instead generate a General Protection exception).
Post Reply