Date: Fri, 26 Aug 2016 10:48:29 -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: <FAC00440-3791-480F-AE24-34D2CD6B6312@bsdimp.com> In-Reply-To: <ae0c18a7-3d9a-708d-bfde-4ce9d6162b76@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>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_7348908C-1D39-41E3-AA39-FA85F423750A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > 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 >>>=20 >>> On 08/26/16 05:56, Konstantin Belousov wrote: >>>>=20 >>>> On Thu, Aug 25, 2016 at 05:50:31PM -0500, Pedro Giffuni wrote: >>>>>=20 >>>>> 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. >>>>=20 >>>> 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 >>>=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 >>>>>=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 >>>>=20 >>>> There are objections, the change must be runtime tested on large = and >>>> representative set of real-world applications before turning the = knob. >>>>=20 >>>=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. >>=20 >> 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 >=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). I get very nervous when I see =E2=80=9Cshould work=E2=80=9D or =E2=80=9Csh= ould be platform independent=E2=80=9D for such a low-level thing. Warner --Apple-Mail=_7348908C-1D39-41E3-AA39-FA85F423750A 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 iQIcBAEBCgAGBQJXwHLdAAoJEGwc0Sh9sBEARkQP/jN4/Y0azhX4ASQW5PU97z+u ee5nWbUqVlJCRzpeTl33sHBuBmAbq/nrkcOyDtsMz9jWkvl0/Ei7/6FpkYyYJk8b Ret06oB/2Ia7KO2Hajj/4yS5g13tRm4tHnzZZi+1KMsEBI/VNIeJRWgPN1o/4cre yByqpAZzgaf8X5C4SHydAzruVlmZLaJ+AJ53mWNoBj45xRw96yUDxx4MQ5KSntkZ SDbXUCno9OyPq4PblnO7Ai8PIAhgPdPU0Z/p3mV2QguCoz20POa2Y7x1Y/xZoIO8 fp1iHXgdAJVyS4LgrosdpE7hb1Qpzu6HWa+vXVKDGzRA8+ocn35IYLKQ3a1B2vci O1vLGRfEbB7KtgqWfoJcvGhLggphxBo3N/z2qlldYbSu24Z8maiD1hU6SiKuZVbL 3DwRrIlxhr7Bhf0kqoZFTNvNUyQWdx8uvynXgrEOa/95m16VWfYsT4RYeKFrrwLp KhngSl13k4UFv8s84Qs6nn6msX6+YQ2RPporrFTAMyqJ7QjV5SslXdn7U7uYXelm 0oAd8EB3ZK6QifqMuJbqTPgVS2ZHEqsQL+0LlTV410oAT8JeH7Xe8TiSW+1/ppkU PskA9qfKgD+Oi7pJAWFBoSLZ0notSVhxuZ6igYaAd5nx3zVbWDgvquU08xrGR5W2 9VABo2uEEsMlhW6oswem =9UzM -----END PGP SIGNATURE----- --Apple-Mail=_7348908C-1D39-41E3-AA39-FA85F423750A--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FAC00440-3791-480F-AE24-34D2CD6B6312>