Messages in this thread | | | Date | Fri, 3 Jan 1997 19:47:30 -0500 | From | "David S. Miller" <> | Subject | Re: Kernel stack corruption with SCSI |
| |
Date: Fri, 3 Jan 1997 19:21:05 +0100 (MET) From: Ingo Molnar <mingo@pc5829.hil.siemens.at>
[ .. ]
#define alloc_kernel_stack() vmalloc(4096) #define free_kernel_stack(page) vfree((page))
[ ... ]
thus all kernel stacks are MMU protected and separated by a zero pte? I havent checked this (yet), just wondering wether someone has done this already. This is a bit safer (and the resulting fault is much more informative).
(As someone already mentioned this suggested scheme would triple fault and require some new trap glue to recover from completely)
We effectively do the above on the older sun4c Sparcs. This was out of necessity because the stack must be locked down in the TLB because trap entry code which runs with traps disabled must never fault when accessing the kernel stack, yet they must get at it in this state to save away the cpu registers before enabling traps again.
So I set aside a portion of the kernel virtual address space to map task_struct's and kernel stacks, I put these into distinct 4 page chunks. And therefore I make sure the page right below the bottom of the kernel stack is not mapped. If the kernel stack ever became that large one of two things would happen on the sun4c:
a) if the first out of range stack accessed happened with traps off as described above, the machine would incur a "watchdog reset" which essentially drops you into the PROM monitor, at such a point you cannot return to the kernel to sync disks or anything but you can get dumps of all the cpu registers at the time of the reset and disassemble the code it was executing
b) else if traps were on you'd get a kernel fault which would try to save the register state with traps off and you end up with situation 'a' anyways
It's a tough problem to solve satisfactorily.
---------------------------------------------//// Yow! 11.26 MB/s remote host TCP bandwidth & //// 199 usec remote TCP latency over 100Mb/s //// ethernet. Beat that! //// -----------------------------------------////__________ o David S. Miller, davem@caip.rutgers.edu /_____________/ / // /_/ ><
| |