From owner-freebsd-stable@FreeBSD.ORG Mon Oct 5 16:55:07 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACEA01065670 for ; Mon, 5 Oct 2009 16:55:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id 3DF548FC08 for ; Mon, 5 Oct 2009 16:55:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id F0D6141C6FC; Mon, 5 Oct 2009 18:55:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id Yw+lEYzWJQa7; Mon, 5 Oct 2009 18:55:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 7702941C6F2; Mon, 5 Oct 2009 18:55:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 92D1F4448E6; Mon, 5 Oct 2009 16:50:59 +0000 (UTC) Date: Mon, 5 Oct 2009 16:50:59 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Mike Tancsa In-Reply-To: <200910051448.n95EmVcd025214@lava.sentex.ca> Message-ID: <20091005163052.Q5956@maildrop.int.zabbadoz.net> References: <20091003184220.GA2620@curry.mchp.siemens.de> <20091003212308.GA3122@curry.mchp.siemens.de> <20091003215821.V26486@maildrop.int.zabbadoz.net> <20091004164756.GA6021@curry.mchp.siemens.de> <200910051448.n95EmVcd025214@lava.sentex.ca> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: jhell , stable@freebsd.org, Andre Albsmeier Subject: Re: security.bsd.map_at_zero=0 problem with samba33 (including solution) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 16:55:07 -0000 On Mon, 5 Oct 2009, Mike Tancsa wrote: Hi Mike, >> > Thanks for reporting the issue. People are aware of the problem now >> > and we'll try to present a solution within the next days for better >> > position-independent executable (PIE) handling. >> > >> > Meanwhile there are multiple solutions for people affected: >> > >> > (1) recompile the port; but as more than just samba might be affected >> > and we generally do not want to flip the pie switch everywhere >> that's >> > probably only a temporary, private solution. >> >> I'll stick to this since I am happy about having the map_at_zero >> option and want to continue to try it out on 7.2-STABLE. And I >> see now reason why samba has to be linked with -pie (without -pie >> it is also 4% smaller). > > Hi, > What are the impacts (if any) of compiling all the ports with PIE disabled > that are effected by setting security.bsd.map_at_zero=0 ? Basically in first place compared to yesterday, there is no impact if you do it privately as it will not make much, if any, difference as PIE support in FreeBSD so far has basically been non-existent and was more working out of luck, according to my current understanding. Actually there is a slight difference that I should mention. With PIE valid user code is currently mapped at virtual address 0. That's why it started to fail for people setting map_at_zero to 0. So NULL pointer dereferences in applications like samba will not lead to the obvious error but will point at something, which in that case usually will be garbage and the application will either not work as intended (well that's alsready the case with a NULL derefernce;) or crash in random code (as a later consequence of the NULL deref). In the future though, it seems we will support PIE and in that case you'll get mappings at different place, in the end ideally slightly random so that it'll be hard to exploit the code itself as people no longer can easily pre-guess where things are in virtual memory. Disbaling PIE now means, that this will not happen later but you'll have the fixed (entry point) address, unless you recompile the ports again. I said, no impact if you do it privately above; the problems for the ports crew here are: 1) the entire set of ports affected by PIE is unidentified. 2) they build packages for 6/7 and 8, if not yet 9 as well soon for multiple architectures and cannot just rebuild everything. 3) they can especially not just rebuild the package set for the upcoming 8.0-RELEASE (don't ask, I don't know when it'll happen;). 4) basically they shouldn't need to care about which way the port (read the package as released by its devlepors) choses to be compiled by default. I do not have strong arguments if PIE makes a lot of sense but it seems that for the long term we'll have to support it, as parts of the other world support it as well, and once we support it even old packages will then continue to work even if people disable mapping_at_zero or if the release by default does that. /bz -- Bjoern A. Zeeb It will not break if you know what you are doing.