From owner-freebsd-arch@FreeBSD.ORG Fri Oct 17 14:06:06 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 F1DF35BB for ; Fri, 17 Oct 2014 14:06:06 +0000 (UTC) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) (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 B0E68BBF for ; Fri, 17 Oct 2014 14:06:06 +0000 (UTC) Received: by mail-ie0-f170.google.com with SMTP id rd18so811292iec.1 for ; Fri, 17 Oct 2014 07:06:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=tXHMC0Fnbqz7ZiBIXKwHMFjJnCNSpr7ARW6NhZuFdbk=; b=DuRa9jTAoWM7kM4649TMcP9CPgD1hBUy7+4uEP5tNTHThIMIbSCP9z1tH/+1ptvJNs cGBA5Bcq7RXXUbOkFpN1GHrHHC4UXk3jw0eI1EaRtHwG9QkD2HRWH+nyGxdoWqGPI4Gm FNL5HbYi0lHEWTJm0Qa9TtP6sc5gaKeD9yoSptkbtCordUZ7S60lhX5eF7ZEbjYnCCc8 dQKI3knDWzt2ao66RO4DvAGBwmHr3P78PTfAsGn/MeAQSZS6s0B+DhVR6oKwC9wovx1R bkZZHriY3cVQsdbxY+yFCIuyzv7A5+mFEU8Ga4pTG/InZdCRxVMVzO4By1iffPpnpQLo /2rw== X-Gm-Message-State: ALoCoQlOCvOdvMvI/CZtwsKLUZc3+HHgk6wOESd25LQFeDIpEJSyccKpqv4gLk+DkAQ+uMmjaIua X-Received: by 10.50.111.132 with SMTP id ii4mr12661582igb.39.1413554760437; Fri, 17 Oct 2014 07:06:00 -0700 (PDT) Received: from bsdimp.bsdimp.com ([50.253.99.174]) by mx.google.com with ESMTPSA id o101sm678056ioi.20.2014.10.17.07.05.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 17 Oct 2014 07:05:59 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_F6EE233D-E5F0-4992-82A3-B31CF2F911A4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: PIE/PIC support on base From: Warner Losh In-Reply-To: Date: Fri, 17 Oct 2014 08:05:57 -0600 Message-Id: References: <315B4DC5-0E04-4F6B-BBB0-477D049025BF@bsdimp.com> To: Shawn Webb X-Mailer: Apple Mail (2.1878.6) Cc: PaX Team , 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: Fri, 17 Oct 2014 14:06:07 -0000 --Apple-Mail=_F6EE233D-E5F0-4992-82A3-B31CF2F911A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 [[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: >=20 > On Oct 17, 2014, at 2:05 AM, Shawn Webb wrote: >=20 > > 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. >=20 > 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=92t, > 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=92t to be used and the history behind some of my reactions. :) >=20 > For this reason, I think WITH_PIE, as I understand your proposal, > likely isn=92t a good fit with other WITH_xxx variables used in the = src > tree today. >=20 > 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=92m saying we don=92t 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 =93go ahead and = use it and I=92ll fix it.=94 I=92m still cool with that position, btw. As for a name, that can be debated a lot, but I=92d like to see = something new, easy to use and unambiguous. If you are looking for a suggestion for that name, let=92s 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. =93Go with this flow." WANTS_PIE=3Dyes means that if MK_PIE is =93yes=94, then do PIE things = for this thing we=92re building. If MK_PIE is =93no=94, though PIE is = disabled for everything. WANTS_PIE=3Dno means that if MK_PIE is =93yes=94, 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 =93I need foo to build, and if MK_foo is set to no, don=92t build me.=94 I don=92t 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.=20 If you go with WANTS_PIE, then you wouldn=92t need bad.*.pie.mk. Comments? Warner --Apple-Mail=_F6EE233D-E5F0-4992-82A3-B31CF2F911A4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUQSJFAAoJEGwc0Sh9sBEAZA0QANkEzzPHyDL5PhCwzBSA0jhO dJz2z9fbcFavg13uEuabUvIHBq4XX7tqc1k4hCsIlrjK/alsyizBjvATut5wyyNJ OnMY+rg5zfM2Bj5ujuV2NtUlhKoYC0Gw5YQGwNl5T+7OCDOh0QUJCjGP1I2M4ScP HQSkT5byusQoOKJmQnC/JRBD6jxKXzVfQ9ea1Yy/PtuVXjIT95tSOxFW+t/rVWP/ kpPgNGDr7n06HG3gRldJC8P8HTB76ElheM73nELwzHf3D0ZkRwyhbvHoeVQSqQUY sI2d3PY9wV7ITMlhTNvkOGs/TA3jhwNDDbXDWg2I3UgVkvMixbd+um7r4MZrPbrd jiY/q3cF3Wbf5MFlTnqWqB7nM0e1dcjG21fCh1yk1z8Q2k9PRVmnKmb8Wl/7G96S NenRpFKEcWQp4AKLOrV2kAGRYYn753FLiLzqF+SHzl1fVFdWoXUDSscvbv86MyJn ufERZ4E6aXY+HLYQz6Uquq5QeAm3TgsRDlhzfkXqb4EKZi6p8S1yjPH77inMet9H FIxJFQQRpoYwij3XMjZW6wgKQbT4+Liah442mSSmM03WgItidTAArBXYzq/uGokJ oTpLcZX5FhM9pVS0RL4LSyvU6J4lK1nllbPQhaOZyjVZf81eQZXoOkKwWSB0cXHM JuhAcjKQqK0dHe1kFeyo =P4l5 -----END PGP SIGNATURE----- --Apple-Mail=_F6EE233D-E5F0-4992-82A3-B31CF2F911A4--