From owner-freebsd-arch@FreeBSD.ORG Fri Oct 17 13:41:28 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 529F98FD for ; Fri, 17 Oct 2014 13:41:28 +0000 (UTC) Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com [209.85.213.173]) (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 0E348978 for ; Fri, 17 Oct 2014 13:41:27 +0000 (UTC) Received: by mail-ig0-f173.google.com with SMTP id h18so1584921igc.6 for ; Fri, 17 Oct 2014 06:41:26 -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=e2j6houDoBR3t4NsYkb8Aose+yaAcJOd2vR9LcdDCPs=; b=UWcQHFNs7X60xDnmDjd4sfdUmQhMrQcE63JxW5B5tVi9vhqvEs8iOKSGa3XhYvPuV6 /ZFN4VTKJ2QcP0vh1sQP6lu7Ry5DDrLP04NvOuMVvSUtqfK6cPRyp+PlN85I6M4Q1Jma Ms7DYWbSdsNfIyp18J4Win993VwrqdSzQhNKNZ5AoEhHf9yi4RXEFiFSNqZ3UiOX0LwL 2WU9kZROzIF2wUBL4OBpCUTR8pQpMW+t8/07ASPSk2E7B8v7xNvqbKBgNBAPQp/PURyr Eiwmw2B98JCjm9jMYqhaaMG7ti9alm0r+pKZJ8HpPDxpAWIS7a3oFqmV/ohNHt/FR2IC auRA== X-Gm-Message-State: ALoCoQlOLYKTXFP98ZTsSeNQUNS03dkDysngZZGWmPxVep3oUFVeZYeirQpWdDO73CsYAJv+vpVi X-Received: by 10.107.3.25 with SMTP id 25mr2363858iod.69.1413553286536; Fri, 17 Oct 2014 06:41:26 -0700 (PDT) Received: from bsdimp.bsdimp.com ([50.253.99.174]) by mx.google.com with ESMTPSA id o62sm656572ioe.12.2014.10.17.06.41.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 17 Oct 2014 06:41:25 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_C9A81F84-205F-4468-B0E6-6F6B44558AF7"; 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 07:41:22 -0600 Message-Id: <315B4DC5-0E04-4F6B-BBB0-477D049025BF@bsdimp.com> References: To: Shawn Webb X-Mailer: Apple Mail (2.1878.6) X-Mailman-Approved-At: Fri, 17 Oct 2014 13:46:26 +0000 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:41:28 -0000 --Apple-Mail=_C9A81F84-205F-4468-B0E6-6F6B44558AF7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 17, 2014, at 2:05 AM, Shawn Webb wrote: > On Fri, Oct 17, 2014 at 3:53 AM, Jeremie Le Hen = wrote: >=20 >> On Fri, Oct 17, 2014 at 12:15 AM, Shawn Webb = wrote: >>>=20 >>>=20 >>> On Thu, Oct 16, 2014 at 5:59 PM, Jeremie Le Hen = wrote: >>>>=20 >>>> On Thu, Oct 16, 2014 at 8:21 PM, David Carlier >>>> wrote: >>>>>=20 >>>>> 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 ? >>>>=20 >>>> 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? :) >>>=20 >>>=20 >>> Looping in Kostik, Bryan Drewery, the PaX team, Hunger, and Sean = Bruno. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> Those are my two cents. >>=20 >> 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). >>=20 >> Do you know what took so much time to OpenBSD? >=20 >=20 > 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: >=20 > "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." >=20 > 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. >=20 > 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=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. :) 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. Warner --Apple-Mail=_C9A81F84-205F-4468-B0E6-6F6B44558AF7 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 iQIcBAEBCgAGBQJUQRyCAAoJEGwc0Sh9sBEAW7EQAKo+M1fXOG9+zpjbGsMMre+B T2q1Rmo5mUeXjrAX1s7dyraXp39O5XfnCDIQJj82pFF90L1M0kB8wm4trU9QDYEL rhAnVN/ajLYJ8Q89CwhWaW9di08VvciKLfJ3fLPjH3p+NqWBcuY46yiwAzsGpBL0 SDHMS148jW5xAkg2JAGuepanjQeVfjJZUIMO6i/f2jZVUfmupkpl8AqRp+cQiziC ALoxfc3bn1mD8ECXenQFiDzMmAN4fpN4gVaPGvM7YHfaDiEDJVlgJbK3iJqvHdBC vLM4/tvw1DhqF0cJ1drcGEAwafDNILEsCpMdNqzZ+UU5GuD9FG1DO0QyjFUtP8// P50O74Pw6v/oFVQWvwaUqzcQ39txsBgaBcevoO22GgQwwVTx+xX0tIpBDb2jJpnv JgrvjHoDMPePM7r44SaPQgPkntbVGbpjlNmL1o7jSBahkdkWHdkqqOmYZkk+MQ+C RPwB09CyQwavvqFI2NZ7w1FqOiguK0WeQG5VhYTcSzQJQTiv7EBLoikcw+HxkU7Y rEI69poq+zuL7fN7RFibxKnJt30eTXhuvI05/cn9cjZZW/7Uc1KY1FQ1DJTRnqS8 4fW8qhItoena+UXPjtlIUAIQa9HEc4OkgXM8unaEquBoli3RwxUa5xq6fwr6AmIz eOghcbHwfhbgM0R+YwA6 =cajQ -----END PGP SIGNATURE----- --Apple-Mail=_C9A81F84-205F-4468-B0E6-6F6B44558AF7--