On 26/08/2016 19:00, Warner Losh wrote:
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.
And very right you are, this has all the chances of breaking MIPS*:
"A configure option --enable-relro={yes|no} to decide
whether -z relro should be the default behaviour for
the linker in ELF based targets. If this configure
option is not specified then relro will be enabled
automatically for all Linux based targets except FRV,
HPPA, IA64 and MIPS."
_____
I will update the patch to exclude MIPS (and MIPS64 JIC).
Pedro.
*https://gcc.gnu.org/ml/gcc/2016-08/msg00134.html
_______________________________________________
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
