Re: [Solved] Re: Kernel Panic Cluedo
Re: [Solved] Re: Kernel Panic Cluedo
- Subject: Re: [Solved] Re: Kernel Panic Cluedo
- From: Terry Lambert <email@hidden>
- Date: Mon, 27 Nov 2006 13:01:18 -0800
On Nov 27, 2006, at 3:58 AM, Andrew Gallatin wrote:
Michael Smith writes:
Stephane wrote:
It could be cool if there was a Kernel simulator with memory
protection...
Protection of what? Read/write memory in the kernel map is freely
writable by any code within the kernel; this is what being a
"monolithic" kernel is all about.
Optional redzones, as well as use-after-free, use of uninitialized
data, etc, would be welcome. Solaris does this with boot-time
tunables (kmem_flags), and FreeBSD and linux do much of this
with compile time options. A redzone may have caught Stephane's
corruption as it happened..
There is a lot of this type of checking available for allocated memory
(assuming it was allocated memory) with compile time options already.
See the use of "MACH_ASSERT" and "zfree_clear" at the top of osfmk/
kern/zalloc.c, and other code for memory allocation/usage verification.
It doesn't deal with the alignment of allocations against page
boundaries with unmapped pages adjacent to deal with underflow/
overflow trapping (necessary because hardware fails to support sub-
page memory protection), but it covers most of the other bases.
There's also a lot you'd get from compiling a DEBUG kernel, which
mostly nobody does.
For use of uninitialized data, the M_ZERO flag is your friend
(anything stronger requires compiler help).
Meanwhile, code donations for things like this - particularly,
redzones and page end alignment - welcome! Just make sure there
aren't performance penalties in the default case...
PS: Also welcome is hardware that has an implicit concept of sub-page-
sized type-stable memory mapping regions to allow trapping on buffer
underflow/overflow over alignment boundaries (i.e. you might miss an
over/underflow to the next alignment boundary, but hardware help would
reall be the best bet on something like this).
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden