OSDev.org

I read somewhere that interrupt 49 is the only software interrupt that can be reached from ring 3? Is that true? Cause I thought of using software interrupts to do syscalls. And I read that there are no IDT?s for interrupt 50 +. How about this? Can the IDT store 256 interrupts and can I chose which ring to call them from?

Another thing I came to think of. I suppose the privilege level of a interrupt is set by the selector in the IDT, and that DPL is used to tell there computer from where the ISR can be reached. But what happeneds if an application, running in ring 3, causes an exception, and that exceptions has a DPL = ring 0 (which mean that the program running in ring 3 should be able to reach it). Will the exception handler still be called?

For hardware interrupts + exceptions (basically everything that is not "wanted" by the app ) the DPL is not checked. That way you can make sure apps won't fool around with those isrs.

And I guess with that interrupt is specific for one OS ...

Brandon wrote: I read somewhere that interrupt 49 is the only software interrupt that can be reached from ring 3? Is that true?

No, it's not true, you can choose what interrupt you want.
(As long it doesn't conflict with the exception interrupts

Can the IDT store 256 interrupts and can I chose which ring to call them from?

Yes.

Another thing I came to think of. I suppose the privilege level of a interrupt is set by the selector in the IDT.

No, it ain't like that.
You can easily put the code selector to 8 (in the interrupt entry) and the user programs may call the interrupt routine from PL 3.
You can set this up in an IDT entry.
See intel manuals.

But what happeneds if an application, running in ring 3, causes an exception, and that exceptions has a DPL = ring 0 (which mean that the program running in ring 3 should be able to reach it). Will the exception handler still be called?

Yes, if an exception occures, the cpl (the processor calls it though) is 0.
So, yes, it still will be called.


HTH.

I'd recommend using sysenter/sysexit for your system calls. I used to use software interrupts. When I switched over, I noticed a very visible speed increase.

durand wrote: I'd recommend using sysenter/sysexit for your system calls. I used to use software interrupts. When I switched over, I noticed a very visible speed increase.

Yeah, only problem, only "new" processors are supporting it, and not processors like P2, P1, etc.

DennisCGc:
you said "No, it ain't like that.
You can easily put the code selector to 8 (in the interrupt entry) and the user programs may call the interrupt routine from PL 3."

What I meant was; The selector in the IDT decides which ring the ISR will run in. But the DPL decides where I can Call the ISR from. So I can set the DPL = ring 3 And set the selector to whatever segment I want (and by that chose which privileges the ISR should have).

And one more thing. If I set the DPL of an exception to 0. And the exception occurs from a program running in ring 3, the ISR will still be called (as you told me). But can a program in ring 3 call it by asm("INT ..."), or could it only be reached when an exception really occurs?

Brandon wrote: If I set the DPL of an exception to 0. And the exception occurs from a program running in ring 3, the ISR will still be called (as you told me). But can a program in ring 3 call it by asm("INT ..."), or could it only be reached when an exception really occurs?

By setting DPL=3 you are telling the processor, don't let this interrupt handler be called by any privilege level greater than 0. So this means that no, a program in ring 3 cannot just call it with INTn. If an exception occurs, the CPU calls the specified exception handler automatically, without doing any privilege check on it, which is why a ring3 program that generates an exception will correctly enter the exception handler. Basically, for the most part (and at least to start off with), I would recommend just setting all of your interrupt handlers to ring 0 except for your syscall handler. There's really no reason to allow user-land code to fake an exception or device interrupt.

but if they do try to fake an exception, what will then happen? General Protection Fault?

One more thing.. I decided to use int 48 for rebooting the system (just playing around, will change that later on). Anyways, I got an ISR for the RTC-interrupts that works. And I also got a function for sleeping for an amount of milliseconds. This sleep methods counts interrupts triggered by the RTC. I got this function:

void reboot() {
sleep(10);
out(0x64, 0xfe);
}

it works great to call the function (it sleeps and reboot). But if I try to call it via my Int 48 ISR, the sleep function wont work. So if I go this way:
program -> int 48 -> int48-isr ->reboot
the program will hang in the sleep function (and no RTC IRQs will be triggered). How come, the sleep function works great except for when I call it from my INT48-handler

Brandon wrote: it works great to call the function (it sleeps and reboot). But if I try to call it via my Int 48 ISR, the sleep function wont work. So if I go this way:
program -> int 48 -> int48-isr ->reboot
the program will hang in the sleep function (and no RTC IRQs will be triggered). How come, the sleep function works great except for when I call it from my INT48-handler

Well... you probably use an interrupt gate.

To check, see what the interrupt flag is at the moment you try sleep(). My bet is you've disabled interrupts automatically through using an interrupt gate.

Candy: not to be stupid, but what?s an interrupt gate? I just put the interrupt in the IDT (like an IRQ handler or exception)..and then call it using asm("int $48")...

Anyways, how do I clear the interrupt flag so that more interrupts can be called? I got it working by using asm("sti"), is that the best way?

The IDT can hold many different kinds of gates, the most useful being interrupt gates and trap gates. The only difference between those two is that interrupt gates disable interrupts on entry, whereas trap gates leave interrupts enabled. If you want interrupts enabled, don't use an interrupt gate and then enable interrupts on entry, just use a trap gate.

I tried with a trap gate instead of an interrupt gate, works great...

but the thing is, I use interrupt-gate values in my IDT for all exceptions/IRQ.. and the interrupts are Not disabled by that. Only by software interrupts. How come? Cause if interrupts are disabled by calling software interrupts, they should also be disabled when an exception occurs (if I use interrupt gates on both)

Brandon wrote: I tried with a trap gate instead of an interrupt gate, works great...

but the thing is, I use interrupt-gate values in my IDT for all exceptions/IRQ.. and the interrupts are Not disabled by that. Only by software interrupts. How come? Cause if interrupts are disabled by calling software interrupts, they should also be disabled when an exception occurs (if I use interrupt gates on both)

from the 7-page p-code Intel gives for int:
on a cross-permission software interrupt to a nonconforming code segment (say, the default kernel call int), interrupts are cleared if in an interrupt gate.

checking the AMD system programming manual (intel doesn't print, so I don't consider them authoritative.... although amd doesn't print 'm anymore either ):
performs trap/interrupt gate condition on all entries.

Are you damn sure it doesn't?

Have you actually tried waiting for an interrupt in an ISR called by an interrupt gate? Try making your floppy interrupt send a command and wait for another interrupt, I bet it won't come if its a interrupt gate... that is the point of them, after all...

I havent tried that, But... e.g. my keyboard ISR is an interrupt gate.. and I dont have to enable interrupts using "sti" when ?t?s running.. but since it?s an interrupt gate iit Should disable all interrupts until I?ve enabled them?

If I call a software interrupt gate using INT, Im not able to use interrupts at all before I use "sti". But I dont need to use it after e.g. in IRQ.