Page 1 of 1

DPL

Posted: Sun Jul 25, 2004 5:52 pm
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?

Re:DPL

Posted: Sun Jul 25, 2004 6:32 pm
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.

Re:DPL

Posted: Sun Jul 25, 2004 6:59 pm
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?

Re:DPL

Posted: Sun Jul 25, 2004 8:27 pm
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)

Re:DPL

Posted: Tue Jul 27, 2004 10:19 am
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).