From owner-freebsd-toolchain@freebsd.org Sat Aug 27 00:00:35 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B851BB76605 for ; Sat, 27 Aug 2016 00:00:35 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 81F43D5 for ; Sat, 27 Aug 2016 00:00:35 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-pa0-x234.google.com with SMTP id hb8so31478021pac.2 for ; Fri, 26 Aug 2016 17:00:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=qSAPZTn8yvqZWn1b+vCzI5DGmeBP5Q0//h6MeSeRKNM=; b=ALp+Jh0wRfwV04NIWoo32fFPx1yd0sn3Q1PnFMNybDBHUWZdPWk5rnQjQyZheRGEkk 1zMKe/bVHzVnL0aWiKzZP9qBxA3bmHfKQtcKZV8jCCOXt39UJR2/N0CCyUqBvnFa8Wp2 WO+tDhxSVnHaaTJayJjtNTgaUl7IzvQaoU+ARhNahzJI1Rq/6lRfMGqujCVGrPhp2be3 crF/0Jn1rEU6C2vHHElt1AHRsUDm1NuoafauE+oExKzDuoAcXjpEq3ige7kwKxFg1VCv R6kF/F+8zMTvKb9FhMepN4zNfANDPwUe11R+7szBAgYkaLvLPrWRjuARUlfjiaPeM0jI RNsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=qSAPZTn8yvqZWn1b+vCzI5DGmeBP5Q0//h6MeSeRKNM=; b=NU9SPBah0rHFBsg156SN6hKqpRETIfDbXiVezHVm9WP2e7bBAN1mFRrEFjBU0vl2rn 7KKI111dnWmafmzYb1Uke+xLVxAPJGfAWPa84qy5LlaPHwfAuP5waPg61v/Xz1Lmgq0B w0K6sGftzfOXulbbrGRPN3z+ZCR7abxXbEsrhPpChT/mW+qU/GQ0MrR6OSUggn1iEScr Wgrk0uFQ6e94+ZqOix9wBuaoMdyaTTijhCr5L7VzN9NYlbmMDVxrmu4t7Gls7Y/8wZ12 +6kLKyPPZSNdFczYtEMlVbCpTYN5h07yOXZbo5IERfNWe6/SDnRrBpzLvzdkSaro4Ray PftA== X-Gm-Message-State: AE9vXwPniQNTmmTgFbQS9w5YK0+60AHrlcxMcE4Uy168bm1Bi6Ev8cidfRu3qcM0yDotIw== X-Received: by 10.66.237.71 with SMTP id va7mr10567156pac.124.1472256034984; Fri, 26 Aug 2016 17:00:34 -0700 (PDT) Received: from autobvt-1p7qt1t.corp.netflix.com ([69.53.245.200]) by smtp.gmail.com with ESMTPSA id y9sm31368002pay.25.2016.08.26.17.00.33 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 26 Aug 2016 17:00:34 -0700 (PDT) Subject: Re: Time to enable partial relro Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_12AA4AEC-110D-4270-9C25-0530546B1392"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Warner Losh In-Reply-To: <2e5bee0b-0102-8454-9975-e997bd5229ae@FreeBSD.org> Date: Fri, 26 Aug 2016 18:00:32 -0600 Cc: Warner Losh , Konstantin Belousov , "freebsd-toolchain@FreeBSD.org" Message-Id: <04514DD6-F431-490D-9ED6-EBFC9DCE97BF@bsdimp.com> References: <20160826105618.GS83214@kib.kiev.ua> <2e5bee0b-0102-8454-9975-e997bd5229ae@FreeBSD.org> To: Pedro Giffuni X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2016 00:00:35 -0000 --Apple-Mail=_12AA4AEC-110D-4270-9C25-0530546B1392 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 26, 2016, at 12:25 PM, Pedro Giffuni wrote: >=20 >=20 >=20 > On 26/08/2016 11:48, Warner Losh wrote: >>> On Aug 26, 2016, at 9:14 AM, Pedro Giffuni wrote: >>>=20 >>> Hello; >>>=20 >>> On 08/26/16 10:06, Warner Losh wrote: >>>> On Fri, Aug 26, 2016 at 9:00 AM, Pedro Giffuni = wrote: >>>>>=20 >>>>> On 08/26/16 05:56, Konstantin Belousov wrote: >>>>>> On Thu, Aug 25, 2016 at 05:50:31PM -0500, Pedro Giffuni wrote: >>>>>>> Hello; >>>>>>>=20 >>>>>>> GNU RELRO support was committed in r230784 (2012-01-30) but we = never >>>>>>> enabled it by default. >>>>>>>=20 >>>>>>> There was some discussion about it on >>>>>>> https://reviews.freebsd.org/D3001 >>>>>>>=20 >>>>>>> By now, all Linux distributions, NetBSD and DragonFly support it = and >>>>>>> it is the default for most systems in binutils 2.27. >>>>>>>=20 >>>>>>> This doesn't affect performance, I ran it through an exp-run = last >>>>>>> year, no other OS has had issues etc ... seems safe and can be >>>>>>> disabled if needed when linking. >>>>>> Exp-run does not test anything interesting about relro. If all = testing >>>>>> that was done is basically just an exp-run, then there was no = useful >>>>>> runtime testing done. >>>>>>=20 >>>>> The exp-run does cover Java and other VM-type thingies that = bootstrap. >>>>> For upstream binutils this is now the default (at least for linux, >>>>> they never ask us if we want to follow). So the change has been = tested >>>>> extensively but perhaps not on cases that are relevant to us. >>>>>=20 >>>>> Note that the "fix" for any port is ultimately trivial: >>>>> LDFLAGS+=3D "-z norelro" >>>>>=20 >>>>>>> I think it's time to enable it be default in our base binutils. = If >>>>>>> there are no objections, I will just commit the attached patch = over >>>>>>> the weekend. >>>>>>=20 >>>>>> There are objections, the change must be runtime tested on large = and >>>>>> representative set of real-world applications before turning the = knob. >>>>>>=20 >>>>> You are not giving any hint on what would be a "representative set = of >>>>> real-world applications". Given that you committed the initial = support your >>>>> objection stands very high and is a blocker. :( >>>>>=20 >>>>> As I see it committing it now would give ample time to test this = in current >>>>> before it hits any release. If you want more extensive testing = merging it in >>>>> -stable right after the 11-Release is guaranteed to help >>>>> weed out any remaining update ports may need. >>>> I'd say a minimum is 'buildworld' + a test boot on at least Intel = (i386 and >>>> amd64), armv6 and mips (both 32-bit and 64-bit) before we proceed. = How >>>> many of those have we done? >>>>=20 >>> I have been running it my desktop (amd64) for a year now. I can test = i386 in a VM but I doubt it will affect anything. The issue, and it's = probably kib's worry are some rarely used but important ports. Stuff = like erlang, or virtualbox maybe, but as I wrote, the fix (if needed) >>> is trivial by adding a flag to the link command. >>>=20 >>> FWIW, but it is largely irrelevant to us, RELRO is the default on >>> OpenBSD and there is no way out of it there. >> What I=E2=80=99m worried about is that our run time linker may get = the RELRO stuff wrong and that=E2=80=99s a very platform specific thing = and needs to be validated. I also share Kib=E2=80=99s worry about = different ports being broken, but that=E2=80=99s a different issue. = Recent compilers have broken our run time linker on mips, for example, = because they generate new / different relocations than those before. = It=E2=80=99s easy enough to test to make sure that we=E2=80=99re good on = at least the fairly active platforms (i386, amd64, armv6, mips and = mips64) to make sure that nothing bad happens. The others can be tested = in due time (though the powerpc ones likely can be tested easily enough = by the powerpc guys since they are quite active). >>=20 >> I get very nervous when I see =E2=80=9Cshould work=E2=80=9D or = =E2=80=9Cshould be platform independent=E2=80=9D for such a low-level = thing. >=20 > OK, the doubts are very reasonable and it is critical for us to = effectively test > that the runtime linker does the right thing on all platforms = (independent on > their Tier status). >=20 > Now that I think about it, even if I/we do commit the change, it is = perfectly > likely that it won't see the light of a Release: the plans for 12 are = to replace > GNU ld with lld (no ETA) so what ever we do with ld on -current can = stay > in current. It does seem important to have the chance to test ld+RELRO > at least for a while before moving to lld to make sure things work as = they > should. I think we should move forward, just want to make sure it doesn=E2=80=99t = break some arch completely before moving ahead. While lld is a goal, the = goal is also to have a ld.bdf installed for 12, iirc, as a fallback. Warner --Apple-Mail=_12AA4AEC-110D-4270-9C25-0530546B1392 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 iQIcBAEBCgAGBQJXwNggAAoJEGwc0Sh9sBEAmaIQAN7qgSJerQvZ3vqi2ogmJ0jy Qz+M7Vm11gqj79ppQx0jvWpGY+R2q8mDahd398/quJ6b4VDTJQlu3knCdja0Sdo+ fEVbfuB6lqXOwMmi5Jm0gM38S6I1AHndnkR+Wg4TXZVXxcZFVll/UHr+nfKOn4Xz 1mM3l1QYVOm0u4vs8rN+XfIUCNUtrvh9KWr50FauKLZ5jHeP3qAsmMMKEqOz0PCD GSf06ufPtjZ+7pr1/HCGC5ARXY2qWbW+F52rdgE1IdA+IE3uW3J/fRVAxk6JlIap mQRgtpNcwTS3IjnzHzZCUlxhEDf0fUqqidY5xGHurxL9W79ld2hCQERqf39+xwm+ HDsNUAHqlcScbCSf+33Ii+kD90qPbuIl4KxAvgvIneSRj1mbThDRFKr5xxU6FmEu F5wV+sEVXk0Ytob5czrMPARPjLXuE1du2EDx1PnsBHj+LkI3B8W59rG2IzajSF0V SpgDe94K9TiBdHOAgwsw39Z+hMjNhBNwGXkw9m+OBLshMQzNPWrzgc9+GCVmgDfz ps1eag1nXS/2qxoNwo9f2QJwZmvCocfWQkXALMW7V3HhMBn0AKQOe9saihEtLsHM DY8WYbh+B/CgSZ3FieCi5w8u4w+WyScHh6bt96q3uKVG+8qk8nupf5dsA/yHSIJs AYzFzxVAMkJOMtQO8UsE =6p/W -----END PGP SIGNATURE----- --Apple-Mail=_12AA4AEC-110D-4270-9C25-0530546B1392--