Date: Fri, 18 Sep 2009 23:04:27 +0200 From: Pieter de Boer <pieter@thedarkside.nl> To: Julian Elischer <julian@elischer.org> Cc: freebsd-security@freebsd.org Subject: Re: Protecting against kernel NULL-pointer derefs Message-ID: <4AB3F5DB.5070304@thedarkside.nl> In-Reply-To: <4AB3BEC7.6090409@elischer.org> References: <4AAF4A64.3080906@thedarkside.nl> <20090919.001313.110616099.hdk_2@yahoo.co.jp> <b8592ed80909180852r6f088176oe60fe598b797d636@mail.gmail.com> <4AB3BEC7.6090409@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian wrote: > The assumption is that the userland and kernel share a memory map. > While we do implement it this way, it is not necessarily needed. > We do it for performance reasons (each user memory map includes an > identical top section that is the kernel space, so that we do not need > to switch memory page arenas (change CR3) when entering the kernel. > However it might be possible to not do this, and in fact on some > hardware it is mandatory to not do this). > > It would require a page table arena switch with each syscall which > would require flushing the TLBs which would be expensive.. > Hmm I guess I've talked myself out of this as a solution.. :-) So, to be able to run VM86 mode or Wine we could make the NULL mapping protection a configurable kernel option, (defaulting to 'on'?), which doscmd/wine users could turn off. A nicer way would be to be able to map 0x0 in userland while having the kernel use its own 0x0 mapping. Possibly there is a way to do that without making context switches very expensive? Partial TLB flushes?? I also wonder how Linux and (possibly) other OS'es handle this; I can imagine it can easily become quite messy resulting in added security issues or insufficient protection. Anyone have pointers to that regard? -- Pieter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4AB3F5DB.5070304>