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
[-- Attachment #1 --] > On Aug 26, 2016, at 9:14 AM, Pedro Giffuni <pfg@FreeBSD.org> wrote: > > Hello; > > On 08/26/16 10:06, Warner Losh wrote: >> On Fri, Aug 26, 2016 at 9:00 AM, Pedro Giffuni <pfg@freebsd.org> wrote: >>> >>> >>> On 08/26/16 05:56, Konstantin Belousov wrote: >>>> >>>> On Thu, Aug 25, 2016 at 05:50:31PM -0500, Pedro Giffuni wrote: >>>>> >>>>> Hello; >>>>> >>>>> GNU RELRO support was committed in r230784 (2012-01-30) but we never >>>>> enabled it by default. >>>>> >>>>> There was some discussion about it on >>>>> https://reviews.freebsd.org/D3001 >>>>> >>>>> By now, all Linux distributions, NetBSD and DragonFly support it and >>>>> it is the default for most systems in binutils 2.27. >>>>> >>>>> 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. >>>> >>> >>> 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. >>> >>> Note that the "fix" for any port is ultimately trivial: >>> LDFLAGS+= "-z norelro" >>> >>>>> >>>>> 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. >>>> >>>> >>>> There are objections, the change must be runtime tested on large and >>>> representative set of real-world applications before turning the knob. >>>> >>> >>> 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. :( >>> >>> 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? >> > > 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. > > 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’m worried about is that our run time linker may get the RELRO stuff wrong and that’s a very platform specific thing and needs to be validated. I also share Kib’s worry about different ports being broken, but that’s 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’s easy enough to test to make sure that we’re 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 “should work” or “should be platform independent” for such a low-level thing. Warner [-- Attachment #2 --] -----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-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FAC00440-3791-480F-AE24-34D2CD6B6312>