Pergunta

I'm trying to handle Kernel interrupts via the IDT. I work on Intel x86 under Linux.

I have set my IDT and my interrupts entries and I launched some tests to view my interrupts handlers.

When I try int $0x0, it works perfectly: my handler is called but when I try some exception with error code pushed, I enter in an infinite loop.

The schema is the following:

When an exception arrives, the first part of my handler is in ASM and calls a common C part.

my_handler.c

void handler(int i)
{
  printf("Exception %d caught\n", i);
}

my_handlers.S

common:
    pushal

    pushl %ds
    pushl %es
    pushl %fs
    pushl %gs

    addl $48, %esp                  // 4 4-bytes segments pushed
                                    // + 8 4-bytes registers (pushal)
`                                   // esp points on exception code

    call handler                    // call the C handler with exception code

    subl $48, %esp

    popl %gs
    popl %fs
    popl %es
    popl %ds

    popal

    addl $8, %esp                   // 4-byte error code + 4-byte exception number
    iret


exception_de_handler:
    pushl $0                        // Fake error code
    pushl $0                        // interrupt number
    jmp common

exception_gp_handler:
    // error code is pushed by µproc.
    pushl $13                       // interrupt number
    jmp common

exception_pf_handler:
    // error code is pushed by µproc.
    pushl $14                       // interrupt number
    jmp common

If I try to run the followig code:

int* a = 0x0;
*a = 42;

It works, the exceution resumes after the *a = 42;

But if I try:

int* a = 0x0;
*a = 42;
*a = 1337;

It goes in an infinite loop:

Exception 14 caught
Exception 13 caught
Exception 13 caught
Exception 13 caught
Exception 13 caught
        .....
Exception 13 caught
Exception 13 caught
Exception 13 caught
        .....

Why is first exception Page Fault(14) handled then looping on General Protection(13)?

Thank you for your answers.

Foi útil?

Solução

I think you are messing up your stack. You need to be very careful about what you do with your stack in an interrupt handler. In this case it seems you do the following:-

Push error code (can be done by CPU) Push regs Push segment regs

add 0x48 to the stack pointer, to wind the stack all the way back up so it points to the error code.

call your C function

What this is in effect doing is "freeing" the portion of your stack that the segment registers were stored in. In fact you don't even need to worry about the C function at all because the return address gets pushed onto the stack at the call instruction and blows away your record of ds and es before you even get to the C-call. When you get back from the C call, you try to tidy up the callstack, but you don't get it quite right - partly because you've already messed it up, and partly because you don't clean up the stack after the function call (assuming that handler uses the _cdecl calling convention).

This causes you to pop a bogus value for ds. When you load that into ds the CPU checks the value against the GDT, and finds that it is invalid. At this point it raises a GPF (exception 13) which you are seing. That, to a certain extent, recovers the stack (the CPU is looking after the SS for you) and leaves the old value of ds set - so you never actually change ds, which allows you to run printf again.

You need to be much more careful about aligning the stack, and whenever you add to the stack pointer as you do, you need to consider the data that was in that range gone forever because either the next guy, or possibly an unexpected interrupt, is going to trip you up.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top