OSDev.org

I am attempting to write a secure and robust general-purpose event system.

As of now, the keyboard driver makes use of the system.

This is the control flow from keypress to event handler:


This ring-3 call wrapper took quite a bit of clever coding and debugging to achieve. However, when I attempt to return from the event handler, in reverse order, back to the position at which the IRQ1 handler interrupted at, I simply seem to jump back to the line after the ring-3 call wrapper returns.

This is frustrating.

Source: https://github.com/rizet/micron/tree/waspaloy-alpha

I don't see tss_rsp0 being updated anywhere, so you are overwriting the interrupt handler's stack.

tss_rsp0 is updated in setup_syscalls:user/syscalls.asm.
Besides, I don't ever use the stack before I switch back to the same stack that was being used before the ring-3 switch. [source: ring0_return:drivers/evsys/callring3.asm]

Your interrupt handlers clobber R8-R11 and R14.

Why do you have a variable named tss_rsp0 that isn't the RSP0 field in the TSS?

Where do you update the RSP0 field in the TSS?

I made tss_rsp0 for quick/easy access to the TSS rsp0 field when I need to access it in assembly.

I update the RSP0 field in the TSS here: https://github.com/rizet/micron/blob/waspaloy-alpha/kernel/src/cpu/tss.cpp#L31.

So it's the address of RSP0. That means you're putting the stack inside your TSS.

No, it's the value of RSP0.

Look, I'm pretty sure tss_rsp0 is accurate. My syscalls work perfectly fine.

Let me just check if I'm understanding this correctly.

You set RSP0 in the TSS when you initialize your kernel.

Then you get an IRQ in ring 3, which pushes its return address onto the RSP0 stack.

Then you call your user mode function and use INT 0x80 to return, which pushes its return address onto the same RSP0 stack, overwriting the IRQ handler's return address.

Is that right?

1) Yes. I do set RSP0 in the TSS.
2) I do get an IRQ in ring 3, but it pushes its return address onto the IST1 stack.
3) INT 0x80 uses the IST2 stack, not the IST1 stack.

So what happens if you get another IRQ while your ring 3 call is running in response to the first IRQ?

Pretty disastrous.

So, maybe you shouldn't allow IRQs in your ring 3 call.

But if you don't allow IRQs, the ring 3 call could deadlock the kernel.

Other OSes don't directly call ring 3 code. Instead, they have threads that sleep until a specific event occurs, and one possible event is an IRQ. Since they're ordinary threads, they can be interrupted like normal.