Date: Fri, 26 Aug 2016 18:00:32 -0600 From: Warner Losh <wlosh@bsdimp.com> To: Pedro Giffuni <pfg@FreeBSD.org> Cc: Warner Losh <imp@bsdimp.com>, Konstantin Belousov <kostikbel@gmail.com>, "freebsd-toolchain@FreeBSD.org" <freebsd-toolchain@freebsd.org> Subject: Re: Time to enable partial relro Message-ID: <04514DD6-F431-490D-9ED6-EBFC9DCE97BF@bsdimp.com> In-Reply-To: <2e5bee0b-0102-8454-9975-e997bd5229ae@FreeBSD.org> References: <b75890eb-d8bd-759e-002f-ab0c16db0975@FreeBSD.org> <20160826105618.GS83214@kib.kiev.ua> <a9e93c24-9c30-29e4-b949-faa1a7928606@FreeBSD.org> <CANCZdfrJmYcJHXcXaq0qEiy4qif06SX1LNjUi0g=HG=yp8v4TA@mail.gmail.com> <ae0c18a7-3d9a-708d-bfde-4ce9d6162b76@FreeBSD.org> <FAC00440-3791-480F-AE24-34D2CD6B6312@bsdimp.com> <2e5bee0b-0102-8454-9975-e997bd5229ae@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <pfg@FreeBSD.org> wrote: >=20 >=20 >=20 > On 26/08/2016 11:48, Warner Losh wrote: >>> On Aug 26, 2016, at 9:14 AM, Pedro Giffuni <pfg@FreeBSD.org> wrote: >>>=20 >>> Hello; >>>=20 >>> On 08/26/16 10:06, Warner Losh wrote: >>>> On Fri, Aug 26, 2016 at 9:00 AM, Pedro Giffuni <pfg@freebsd.org> = 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?04514DD6-F431-490D-9ED6-EBFC9DCE97BF>