This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 5/7] elf: Enable relro for static build
On 02/12/2019 15:25, Florian Weimer wrote:
> * Adhemerval Zanella:
>
>>> Somewhat bizarrely, full RELRO for statically linked binaries
>>> requires linking with -z now.
>
>> My understanding it is arch-specific and also depends on how
>> bintuils was build. For instance, with my system ld (GNU ld (GNU
>> Binutils for Ubuntu) 2.30) seemed to be built with
>> DEFAULT_LD_Z_RELRO (set by --enable-relro) which sets relro by
>> default. With this binutils I could only disable relro by explicit
>> add norelro, the -z {lazy,now} did not change the GNU_RELRO header
>> creation.
>
> Whether -z relro gives you full RELRO depends somewhat on the
> architecture and what relocations can be eliminated from the static
> link. Objects built with -fPIC tend to leave relocations behind,
> though, and to protect them, you need -z now.
>
I was investigating in fact if binutils is requiring the -z now
to actually enable full RELRO, but it seems that there is no
option to actually set 'full RELRO' besides the combination
of -z now and -z relro.
And I think it is worth to check for static PIE as well. At least
for partial relro, .data.rel.ro seems to protect the required
data.
About testing, I am not sure what kind of coverage we are aiming
here. My initial approach would to check if a write on a variable
set to .data.rel.so does trigger a SEGSEGV signal and check with
some different combinations (-z now, -z lazy, static, dynamic,
pie, nopie). Do you have something more elaborated in mind?