Dispatching signal handlers on a process in kernel-mode
Posted: Sat Aug 25, 2007 5:05 am
Sorry for the strange title, but it wouldn't let me write a bigger one and I couldn't condense my problem into 64 characters
I'm calling signal handlers (actually RPC calls, but that's by-the-by, they act in exactly the same way) as linux does - by waiting until the process is due to be scheduled, then doctoring the stack so that IRET returns to my code, my code is run then it returns to the user's code. It also doctors the user's stack, so my signal handler code can access parameters like the eflags state it should leave with and the eip to return to etc.
This works fine, except when the process which was interrupted was running in kernel-mode. In this case, the interrupt doesn't push a user ESP value, and my code gets confused and tries to doctor a stack at addess 0x0. Currently I just test if the CS is 0x08 and ignore in this case, but that is leading to serious starvation if one process is spinning in a kernel function, and another is waiting for it to respond to a signal.
What is the best way to handle this? I can't doctor the stack that IRET returns to, as it doesn't actually change stacks, just pops, and I can't overwrite any of IRET's parameters... The only thing I can think of is to have a temporary storage area and write there. But it seems awfully kludgy - has anyone got a solution?
Cheers,
JamesM
I'm calling signal handlers (actually RPC calls, but that's by-the-by, they act in exactly the same way) as linux does - by waiting until the process is due to be scheduled, then doctoring the stack so that IRET returns to my code, my code is run then it returns to the user's code. It also doctors the user's stack, so my signal handler code can access parameters like the eflags state it should leave with and the eip to return to etc.
This works fine, except when the process which was interrupted was running in kernel-mode. In this case, the interrupt doesn't push a user ESP value, and my code gets confused and tries to doctor a stack at addess 0x0. Currently I just test if the CS is 0x08 and ignore in this case, but that is leading to serious starvation if one process is spinning in a kernel function, and another is waiting for it to respond to a signal.
What is the best way to handle this? I can't doctor the stack that IRET returns to, as it doesn't actually change stacks, just pops, and I can't overwrite any of IRET's parameters... The only thing I can think of is to have a temporary storage area and write there. But it seems awfully kludgy - has anyone got a solution?
Cheers,
JamesM