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
- From: Florian Weimer <fw at deneb dot enyo dot de>
- To: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- Cc: libc-alpha at sourceware dot org
- Date: Mon, 02 Dec 2019 19:25:11 +0100
- Subject: Re: [PATCH 5/7] elf: Enable relro for static build
- References: <20191129210327.26434-1-adhemerval.zanella@linaro.org> <20191129210327.26434-5-adhemerval.zanella@linaro.org> <874kykfjyy.fsf@mid.deneb.enyo.de> <104ece90-2d18-d655-dafd-1084e32a9c4f@linaro.org>
* 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.