Date: Sat, 27 Aug 2016 13:32:23 -0500 From: Pedro Giffuni <pfg@FreeBSD.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: "freebsd-toolchain@FreeBSD.org" <freebsd-toolchain@freebsd.org>, Warner Losh <imp@bsdimp.com>, Baptiste Daroussin <bapt@FreeBSD.org>, Mark Millard <markmi@dsl-only.net> Subject: Re: Time to enable partial relro Message-ID: <5fe3c09d-7a01-25c7-43de-c7176755a96b@FreeBSD.org> In-Reply-To: <20160827174544.GC83214@kib.kiev.ua> 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> <FAC00440-3791-480F-AE24-34D2CD6B6312@bsdimp.com> <2e5bee0b-0102-8454-9975-e997bd5229ae@FreeBSD.org> <04514DD6-F431-490D-9ED6-EBFC9DCE97BF@bsdimp.com> <b3e0a564-861b-1719-f2f5-b53d70e90d72@FreeBSD.org> <f2a1dcc3-0853-6b71-989c-9a29d335a7af@FreeBSD.org> <20160827174544.GC83214@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On 08/27/16 12:45, Konstantin Belousov wrote:
> On Sat, Aug 27, 2016 at 11:06:54AM -0500, Pedro Giffuni wrote:
>>
>>
>> On 08/26/16 20:10, Pedro Giffuni wrote:
>>>
>>>
>> ...>> 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
>>>
>>
>> Looking more into this, and the arm report from Mark Millard (thanks!),
>> binutils has tests for RELRO in their testsuite that would be an
>> important indicator before enabling the option.
>>
>> It surprises me that we don't have an easy way to run those checks from
>> the port, so I borrowed the regression-test mode from GCC and I am
>> attaching it.
>>
>> The tests may depend on some gnu-isms but we don't appear to do too
>> well on the tests:
>>
>> === ld Summary ===
>>
>> # of expected passes 511
>> # of unexpected failures 78
>> # of expected failures 4
>> # of unresolved testcases 35
>> # of untested testcases 1
>> # of unsupported tests 9
>> /usr/ports/devel/binutils/work/binutils-2.27/ld/ld-new 2.27
>
> And ? In which way this data is useful or indicative of anything ?
This is just informational. According to the GNU ld commit [1], passing
the tests is the criteria used to decide whether the RELRO should be
enabled on a particular platform. We don't complete all the tests and
it appears the tests break before I get to the relro part:
...
.PASS: test-strtol-20.
gmake[2]: Target 'check-host' not remade because of errors.
gmake[1]: *** [Makefile:2204: do-check] Error 2
gmake[1]: Target 'check' not remade because of errors.
*** Error code 2
Stop.
make: stopped in /usr/ports/devel/binutils
> Why this tests are relevant to the proposed change ?
I will drop the proposed change. We should evaluate individually
each platform before enabling RELRO. At this time I am more worried
about the failing tests and our lack of testing of binutils.
AFAIK, binutils
> tests typically compare ld output against expected binary.
>
> And, number of the unexpected failures in your showcase is quite worrying.
>
It is. Having a knob in the port to run the tests seems important.
Pedro.
[1]
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=647e4d46495f2bfb0950fd1066c8a660173cca40
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5fe3c09d-7a01-25c7-43de-c7176755a96b>