> On Aug 26, 2016, at 12:25 PM, Pedro Giffuni <p...@freebsd.org> wrote: > > > > On 26/08/2016 11:48, Warner Losh wrote: >>> On Aug 26, 2016, at 9:14 AM, Pedro Giffuni <p...@freebsd.org> wrote: >>> >>> Hello; >>> >>> On 08/26/16 10:06, Warner Losh wrote: >>>> On Fri, Aug 26, 2016 at 9:00 AM, Pedro Giffuni <p...@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. > > 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). > > 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’t 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
