Time to enable partial relro

[Warner Losh]

On Fri, Aug 26, 2016 at 9:00 AM, Pedro Giffuni <pfg at 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?

Warner