Thats a wrong assumption, remember that stack POP operation is just updating stack pointer e.g. %ESP register on x86, there is no zeroing out of reclaimed portion of stack. Kernel data may still be lying on the stack and its very easy to access any portion of stack. This is exactly what happens with stack auto variable when they are not initialized, they get garbage value, which is actually previously pushed data on stack, in this case the kernel data.
Rajat
2010/11/23 Venkatram Tummala <venkatram867@xxxxxxxxx>
2010/11/22 Jakub Kiciński <moorray@xxxxx>Hi,
Dnia 19-11-2010 o 06:17:53 Venkatram Tummala <venkatram867@xxxxxxxxx> napisał(a):
2. For the kernel code, is it feasible to the use the user stack? WhyThe answer is Yes, you could. But it would be pretty messy & inconvenient.
do we bother to switch to the kernel stack?
We just don't do it in the linux kernel atleast on x86. Kernel Data Segment
& User Data Segment is different. I guess you could just map the user space
stack in the kernel address space too & use it. Using two seperate stacks is
just more efficient & convenient.
Wouldn't it be a security bug to use the same stack for both? Kernel function's parameters and auto variables would be still sitting above (well, in x86 under ;) stack pointer. Not sure though if attacker could find anything interesting there...
I don't think so. Kernel function's parameters & auto variables on the stack only live until the lifetime of the procedure. If we were using just one stack for both user & kernel, when we make a switch (1) user -> kernel & then (2) kernel->user, the stack would be in the state it was before (1). Its a stack. If procedure A calls Procedure B in single shared address space, they share the stack. When procedure B returns, there is nothing to poke around for Procedure A about Procedure B on the stack.Venkatram Tummala
Regards,
moorray
