hi all, not really a problem but most likely just a stupid question: when you make an IDT table the unused INT's a just full of random data ( i know you can set a limit , but i need INT 0x60 and nothing below until 0x30 ), i tried and "INT $0x50" in my kernel and i got an ERROR: "???", in windows an "access violation", do i have to just wire 256 INT's to my ISR handler and give a "spurious interrupt:" error or am i missing something ?
thx!
non-mapped enterys in the idt
Re: non-mapped enterys in the idt
Hi,
For exceptions, IRQ handlers and IPIs it's easy to protect them with the CPUs built in protection, where applications get a general protection fault if they try to use them as software interrupts. Why not treat intentionally unused IDT entries the same (i.e. make them generate a general protection fault too, by making sure the "present' bit is not set)?
I guess what I'm saying is fill your IDT with zeros instead of leaving random trash in it....
Cheers,
Brendan
Some interrupts aren't intended (by the OS developer) to be used by applications as software interrupts. Some of these will be exception handlers, some will be IRQ handlers, some will be for IPIs (if the OS ever supports SMP) and some will be unused.GLneo wrote:hi all, not really a problem but most likely just a stupid question: when you make an IDT table the unused INT's a just full of random data ( i know you can set a limit , but i need INT 0x60 and nothing below until 0x30 ), i tried and "INT $0x50" in my kernel and i got an ERROR: "???", in windows an "access violation", do i have to just wire 256 INT's to my ISR handler and give a "spurious interrupt:" error or am i missing something ?
For exceptions, IRQ handlers and IPIs it's easy to protect them with the CPUs built in protection, where applications get a general protection fault if they try to use them as software interrupts. Why not treat intentionally unused IDT entries the same (i.e. make them generate a general protection fault too, by making sure the "present' bit is not set)?
I guess what I'm saying is fill your IDT with zeros instead of leaving random trash in it....
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Windows is a 32 bit protected mode system ( at least the modern versions ), which sets up the idt. If you call an interrupt, the system uses the idt, and if the idt entry is for ring 0 , ring 3 processes can not call it. But if you do a division by zero, the processor detects it, switches to ring0 and calls the isr.
If you try to call it manually, the processor checks whether you have the correct ring or not.
If you try to call it manually, the processor checks whether you have the correct ring or not.
set the DPL of the entry to the highest ring you want to be able to call it
then if any soft-int occures, where CPL>int.DPL, then the CPU will trigger a GPF instead
for more information, read section 5.12.1.1
then if any soft-int occures, where CPL>int.DPL, then the CPU will trigger a GPF instead
for more information, read section 5.12.1.1
The Holy Intel Manual wrote: the processor checks the DPL of the interrupt of trap gate only if an exception or interrupt is generated with an INT n, INT 3, or INTO instruction. Here, the CPL must be less than or equal to the DPL of the gate. This restriction prevents application programs or procedures running at privilege level 3 from using a software interrupt to access critical exception handlers, such as page-fault handler, providing that those handlers are placed in more privileged code segments (numerically lower privilege level). For hardware-generated interrupts and processor-detected exceptions, the processor ignores the DPL of interrupt and trap gates.