lkml.org 
[lkml]   [1997]   [Jan]   [3]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateFri, 3 Jan 1997 19:47:30 -0500
From"David S. Miller" <>
SubjectRe: 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 /_____________/ / // /_/ ><

\
 
 \ /
  Last update: 2005-03-22 12:38    [from the cache]
©2003-2008