From owner-freebsd-arch@FreeBSD.ORG Wed Nov 5 09:32:25 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 10EE4B3B; Wed, 5 Nov 2014 09:32:25 +0000 (UTC) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BE2CFBC9; Wed, 5 Nov 2014 09:32:24 +0000 (UTC) Received: by mail-oi0-f42.google.com with SMTP id a3so11155394oib.29 for ; Wed, 05 Nov 2014 01:32:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZrH9JRaT4wNol8N4Ydw8n6oCVPcuJShi3f7Ep71l7Fc=; b=xrBu0Fd/YtR8B0ggvQxxtLvcRFQa8xIw7CUYmFyQmmA8RlrYeMX3Obdkei0oyYtZx/ VfhbgiKstG2a0kSqUJWv8r2mfmW0xkhShuelhO1QrJZA02tpNPl9pWLZ5OKl0dXsIApT 19J8rXiO28H3YnghrKGoq+9EvYPQiwykLFgwE0wdng2X9fBgIxjM4kC6adW8Wmeu9w7N fptnKulMC0dPkM3INK4F3DYXuMZuGmvU0EVyNwr1atgx0EbnYg+2XI/v7qTJvBlQ6rWn g600R04u109LG6g0mAjgD08CKymycwQULL8iX/6MGp7HAF0BGMMHILTOF7EWNc1bs3zC 1uFA== MIME-Version: 1.0 X-Received: by 10.202.61.8 with SMTP id k8mr24729421oia.3.1415179944019; Wed, 05 Nov 2014 01:32:24 -0800 (PST) Received: by 10.202.208.150 with HTTP; Wed, 5 Nov 2014 01:32:23 -0800 (PST) In-Reply-To: <20141105090215.GF10388@ivaldir.etoilebsd.net> References: <315B4DC5-0E04-4F6B-BBB0-477D049025BF@bsdimp.com> <20141105090215.GF10388@ivaldir.etoilebsd.net> Date: Wed, 5 Nov 2014 10:32:23 +0100 Message-ID: Subject: Re: PIE/PIC support on base From: Oliver Pinter To: Baptiste Daroussin Content-Type: text/plain; charset=ISO-8859-1 Cc: PaX Team , Shawn Webb , FreeBSD Arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 09:32:25 -0000 On 11/5/14, Baptiste Daroussin wrote: > On Fri, Oct 17, 2014 at 08:05:57AM -0600, Warner Losh wrote: >> [[cc trimmed ]] >> >> On Oct 17, 2014, at 7:46 AM, Shawn Webb wrote: >> >> > On Fri, Oct 17, 2014 at 9:41 AM, Warner Losh wrote: >> > >> > On Oct 17, 2014, at 2:05 AM, Shawn Webb wrote: >> > >> > > On Fri, Oct 17, 2014 at 3:53 AM, Jeremie Le Hen >> > > wrote: >> > > >> > >> On Fri, Oct 17, 2014 at 12:15 AM, Shawn Webb >> > >> wrote: >> > >>> >> > >>> >> > >>> On Thu, Oct 16, 2014 at 5:59 PM, Jeremie Le Hen >> > >>> wrote: >> > >>>> >> > >>>> On Thu, Oct 16, 2014 at 8:21 PM, David Carlier >> > >>>> wrote: >> > >>>>> >> > >>>>> I chose the "atomic" approach, at the moment very few binaries >> > >>>>> are >> > >>>>> concerned at the moment. So I applied INCLUDE_PIC_ARCHIVE in the >> > >> needed >> > >>>>> libraries plus created WITH_PIE which add fPIE/fpie -pie flags >> > >>>>> only if >> > >>>>> you >> > >>>>> include (which include ...) >> > >>>>> otherwise >> > >>>>> other >> > >>>>> binaries include as usual hence does not apply. >> > >>>>> Look >> > >>>>> reasonable approach ? >> > >>>> >> > >>>> I think I understand what you mean. But I think PIE is >> > >>>> commonplace >> > >>>> nowadays and I don't understand what you win by not enabling it >> > >>>> for >> > >>>> the whole system. Is it a performance concern? Is it to preserve >> > >>>> conservative minds from to much change? :) >> > >>> >> > >>> >> > >>> Looping in Kostik, Bryan Drewery, the PaX team, Hunger, and Sean >> > >>> Bruno. >> > >>> >> > >>> On i386, there is a performance cost due to not having an extra >> > >>> register >> > >>> available for the relocation work that has to happen. PIE doesn't >> > >>> carry >> > >> much >> > >>> of a performance penalty on amd64, though it still does carry some >> > >>> on >> > >> first >> > >>> resolution of functions (due to the extra relocation step the RTLD >> > >>> has to >> > >>> worry about). On amd64, after symbol resolution has taken place, >> > >>> there >> > >> is no >> > >>> further performance penalty due to amd64 having an extra register to >> > >>> use >> > >> for >> > >>> PIE/PIC. I'm unsure what, if any, performance penalty PIE carries on >> > >>> ARM, >> > >>> AArch64, and sparc64. >> > >>> >> > >>> Certain folk would prefer to see PIE enabled only in certain >> > >> applications. >> > >>> /bin/ls can't really make much use of PIE. But sshd can. I >> > >>> personally >> > >> would >> > >>> like to see all of base's applications compiled as PIEs, but that's >> > >>> a >> > >> long >> > >>> ways off. It took OpenBSD several years to accomplish that. Having >> > >> certain >> > >>> high-visibility applications (like sshd, inetd, etc) is a great >> > >>> start. >> > >>> Providing a framework for application developers to opt their >> > >>> application >> > >>> into PIE is another great start. >> > >>> >> > >>> Those are my two cents. >> > >> >> > >> OK. As long as i386 is still an important architecture, it can make >> > >> sense to enable this on a per-binary basis if we don't want to have >> > >> a >> > >> discrepancy between archs. Also I buy your argument on /bin/ls but I >> > >> was challenging to enable for the whole system because I wonder if >> > >> there aren't some unexpected attack surfaces, besides the obvious >> > >> ones >> > >> (servers). >> > >> >> > >> Do you know what took so much time to OpenBSD? >> > > >> > > >> > > In a private conversation with Theo, I realized that my recollection >> > > of the >> > > time it took OpenBSD to compile all of base as PIEs was wrong. Quoting >> > > him: >> > > >> > > "It took 5 people approximately 3 months to debug it, activate it, >> > > and >> > > start shipping it the next release. That was on amd64, for all >> > > dynamically linked binaries, except one (a gcc bug took some time to >> > > find). The next architectures followed about 1 or 2 per 6-month >> > > release." >> > > >> > > Given that only one person has worked on this in the past (me) and now >> > > the >> > > task has been delegated to another (David Carlier), I think we're >> > > doing >> > > okay on our end. There's a lot of moving parts, and neither of us >> > > fully >> > > understand all of them completely. We're working on it in HardenedBSD, >> > > in >> > > the hardened/current/pie branch. >> > > >> > > I'm thinking we might try for a WITH_PIE knob (and *not* use USE_PIE) >> > > and >> > > have certain high-profile applications opt-in to PIE until we work out >> > > all >> > > the details for everything en masse. Baptiste did bring up a good >> > > point >> > > with INTERNALLIB and I'm unsure of how we should handle that. >> > >> > WITH_PIE or WITHOUT_PIE controls, on a global basis, via the MK_PIE >> > variable, whether or not the user wants to turn on this feature for >> > those >> > program that can do PIE. Designating which programs do, or don't, >> > use PIE simply must be done with a different variable. I posted a bit of >> > a >> > rant about the current state of things that suggested a couple of >> > alternatives as well as giving some history as to why some options >> > aren't to be used and the history behind some of my reactions. :) >> > >> > For this reason, I think WITH_PIE, as I understand your proposal, >> > likely isn't a good fit with other WITH_xxx variables used in the src >> > tree today. >> > >> > Gotcha. To be honest, I found your email a tad bit confusing. Are you >> > suggesting we create an ENABLE_feature framework? Or are you suggesting >> > we have a USE_PIE flag? Or are you suggesting something different >> > entirely (and if you are, what?)? >> >> I'm saying we don't have a good framework at the moment to do this. We >> have several bad ones that all have their pitfalls. This is one reason I >> had >> the fast reaction to NO_PIE, then a minute later said "go ahead and use >> it and I'll fix it." I'm still cool with that position, btw. >> >> As for a name, that can be debated a lot, but I'd like to see something >> new, easy to use and unambiguous. If you are looking for a suggestion >> for that name, let's go with WANTS_PIE. Only Makefiles can set it. >> >> WANTS_PIE undefined means do the default behavior as defined by the >> current MK_PIE setting and perhaps system policy. "Go with this flow." >> >> WANTS_PIE=yes means that if MK_PIE is "yes", then do PIE things for >> this thing we're building. If MK_PIE is "no", though PIE is disabled for >> everything. >> >> WANTS_PIE=no means that if MK_PIE is "yes", then disable doing PIE >> things for this component. If MK_PIE is no, it is also disabled. >> >> This could also be extended to NEEDS_foo, which says "I need foo to >> build, and if MK_foo is set to no, don't build me." I don't think >> anything >> that you are doing falls into this category though. >> >> WANTS/NEEDS also avoids the historical use of USE in the ports tree >> possibly creating confusion. >> >> If you go with WANTS_PIE, then you wouldn't need bad.*.pie.mk. >> >> Comments? >> >> Warner > > On amd64 WANTS_PIE will be useless as we can easily activate PIE on every > places > For i386 we would propably prefer cherry picking the what we want to see > built > with PIE. Don't know for other arches. > > So here is what I do propose: > if MK_PIE=no: no PIE at all > if MK_PIE=yes: > - on amd64/(platforms without performance penalty): build everything with > PIE > from libs to prog > - on i386/(platforms with performance penalty): build with PIE if WANTS_PIE > is defined. > > So the difference with the previous approach are: > - No way to opt out PIE for a single binary either totally disable or enable > (I > have encountered no binary so far in the base system which fails with PIE > enabled - again only tested on amd64) > - Activate PIE for both binaries and libraries (no reason not to include > libraries) > > If we are ok with this I will publish a patch with does it in the next > couple of > week. > > We can start by only supporting amd64 as fully PIE first then slowly add > other > platforms. > > What do you think? I think for us (HardenedBSD) this plan is good. If for FreeBSD not, we will integrate the test patch in HardenedBSD. > > regards, > Bapt >