From owner-freebsd-security@FreeBSD.ORG Sat Sep 19 16:36:32 2009 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D7A110656A6 for ; Sat, 19 Sep 2009 16:36:32 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx07.syd.optusnet.com.au (fallbackmx07.syd.optusnet.com.au [211.29.132.9]) by mx1.freebsd.org (Postfix) with ESMTP id 542818FC23 for ; Sat, 19 Sep 2009 16:36:31 +0000 (UTC) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by fallbackmx07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n8JEiXJ1001080 for ; Sun, 20 Sep 2009 00:44:33 +1000 Received: from besplex.bde.org (c122-107-125-150.carlnfd1.nsw.optusnet.com.au [122.107.125.150]) by mail07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n8JEiPuI018281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Sep 2009 00:44:27 +1000 Date: Sun, 20 Sep 2009 00:44:25 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Pieter de Boer In-Reply-To: <4AB3F5DB.5070304@thedarkside.nl> Message-ID: <20090920001841.G933@besplex.bde.org> References: <4AAF4A64.3080906@thedarkside.nl> <20090919.001313.110616099.hdk_2@yahoo.co.jp> <4AB3BEC7.6090409@elischer.org> <4AB3F5DB.5070304@thedarkside.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-security@freebsd.org, Julian Elischer Subject: Re: Protecting against kernel NULL-pointer derefs X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2009 16:36:32 -0000 On Fri, 18 Sep 2009, Pieter de Boer wrote: > 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. Does VM86 mode really require or use mapping to kernel address 0? I think it doesn't and shouldn't, since VM86 mode gets a special %cs which can have a nonzero base address. Hmm, the user %cs is always different from the kernel %cs, so I think it can alway have a nonzero base, but then user addresses would be different from kernel address, which would require large changes and small extra runtime to convert the addresses. VM86 mode would hopefully require only small or null changes since it is already weird. > 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?? Not just context switches, but all kernel entries and exits are relevant. I think the cost of switching the map would be small if you only do it when necessary (on every kernel entry/exit from/to a user context that has pages mapped near address 0). Most switches should be null since most processes shouldn't do that. This can be optimized a bit more by delaying the switch back to the unsafe user map until userland actually accesses a low address. Bruce