From owner-freebsd-security@FreeBSD.ORG Sat Sep 19 17:26:44 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 9D3F81065694 for ; Sat, 19 Sep 2009 17:26:44 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 369508FC13 for ; Sat, 19 Sep 2009 17:26:43 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n8JGmcCe084474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Sep 2009 19:48:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n8JGmbZu002529; Sat, 19 Sep 2009 19:48:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n8JGmb8U002528; Sat, 19 Sep 2009 19:48:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 19 Sep 2009 19:48:37 +0300 From: Kostik Belousov To: Bruce Evans Message-ID: <20090919164837.GF47688@deviant.kiev.zoral.com.ua> References: <4AAF4A64.3080906@thedarkside.nl> <20090919.001313.110616099.hdk_2@yahoo.co.jp> <4AB3BEC7.6090409@elischer.org> <4AB3F5DB.5070304@thedarkside.nl> <20090920001841.G933@besplex.bde.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ufKotkMdkVlnDasC" Content-Disposition: inline In-Reply-To: <20090920001841.G933@besplex.bde.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-security@freebsd.org, Pieter de Boer , 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 17:26:44 -0000 --ufKotkMdkVlnDasC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 20, 2009 at 12:44:25AM +1000, Bruce Evans wrote: > On Fri, 18 Sep 2009, Pieter de Boer wrote: >=20 > >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. >=20 > 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 alrea= dy > weird. In vm86 mode, %cs works exactly the same as in real mode, as well as all other segment registers. vm86-mode code is free to load any 16bit value into any segment register, and virtual address is calculated as (seg << 4) + offset. >=20 > >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?? >=20 > 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. Redhat did that some time ago, but do not any more. --ufKotkMdkVlnDasC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkq1C2UACgkQC3+MBN1Mb4j54gCdFJPQk5Hf/kUJNSRdaxJ/FS6L rOoAoLzIqWK45ZT83ZrL9eW7qKp3q0Ei =YaIS -----END PGP SIGNATURE----- --ufKotkMdkVlnDasC--