From owner-freebsd-arch@FreeBSD.ORG Fri Oct 17 13:46:31 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D7985FAE; Fri, 17 Oct 2014 13:46:31 +0000 (UTC) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (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 B78259CA; Fri, 17 Oct 2014 13:46:30 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id em10so1302587wid.7 for ; Fri, 17 Oct 2014 06:46:27 -0700 (PDT) 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=00tCZSmwvPNhokrwey39VzYEqXhGrtao4vx/BiZg6aw=; b=YXTlJiPie5fUoEgXJZ1JSOAe/l5EMMtnbeU1em8UnSz3UgCZ52RuYibXgjDDen/a2Y n3QbSvG1njm7lISKQfP0v11SI2exM7sYB16p6RKLsMFL5SrJF/AYSVXnf6ITix4QdN7J /yx9BK6NHkRMmRdt1lZ2hMr/1wmioYj78jM89pPcrRgYLnPxg+h2ay9NEu5qK6eAhggl IOGI5i9ilSaGfizOpfQCWmg90fJG9OCzvt9xG7hXQH8Wrzlevl0ATY6NXrr73gY66RvQ XTTksFD4V12fa64kr3U/Hfk/S7SkcYpN1VC/y2gxZBjtXdUzEdsrt9aeHFTzMDp8cSAU 6Jsg== MIME-Version: 1.0 X-Received: by 10.194.121.74 with SMTP id li10mr10336788wjb.40.1413553587771; Fri, 17 Oct 2014 06:46:27 -0700 (PDT) Received: by 10.216.141.6 with HTTP; Fri, 17 Oct 2014 06:46:27 -0700 (PDT) In-Reply-To: <315B4DC5-0E04-4F6B-BBB0-477D049025BF@bsdimp.com> References: <315B4DC5-0E04-4F6B-BBB0-477D049025BF@bsdimp.com> Date: Fri, 17 Oct 2014 09:46:27 -0400 Message-ID: Subject: Re: PIE/PIC support on base From: Shawn Webb To: Warner Losh X-Mailman-Approved-At: Fri, 17 Oct 2014 14:07:30 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: hunger@hunger.hu, David Carlier , Oliver Pinter , PaX Team , Sean Bruno , Konstantin Belousov , FreeBSD Arch , Jeremie Le Hen , Bryan Drewery 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: Fri, 17 Oct 2014 13:46:32 -0000 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 ...) otherwis= e > >>>>> 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 Brun= o. > >>> > >>> 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 car= ry > >> 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 ha= s > to > >>> worry about). On amd64, after symbol resolution has taken place, ther= e > >> 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) a= nd > > 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=E2=80=99t, > 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=E2=80=99t 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=E2=80=99t 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?)? Thanks, Shawn