[PATCH] elf: Support multiple PT_GNU_RELRO segments
Justin Rivera
jnrivera@google.com
Tue Jul 7 18:17:40 GMT 2026
On Mon, Jul 6, 2026 at 5:15 PM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Tue, Jul 7, 2026 at 5:11 AM Justin Rivera <jnrivera@google.com> wrote:
> >
> > Hello,
> >
> > While this patch appears to be working as intended, I had a question
> > regarding any additions to the test suite for testing RELRO behavior.
> >
> > This patch modifies elf/tst-relro-symbols.py, which can statically check
> > ELF headers. However, there don't seem to be any dynamic checks that would
> > work for multiple RELRO segments. We were able to do some ad-hoc testing
> > with some hand-written assembly, but getting something working within the
> > test suite seemed to be a bit trickier. (Often ran into
> > `/usr/bin/ld: foo.so: warning: unable to allocate any sections to PT_GNU_RELRO segment`
> > without some additional patching hack, for example).
> >
> > Are there any suggestions on how to best test the behavior changed by this patch?
>
> We should add the linker support first. Linker can have an option
> to generate multiple PT_GNU_RELRO segments for small binaries.
>
>
> H.J.
Hi,
Could you provide some more details regarding adding linker support?
If you could point me toward
the right place in binutils as well, that'd help tons.
Also, just for additional context, we were able to test this change
locally via a hand-written
assembly ELF binary. We bypassed the GNU linker to emit an ELF file
with two `PT_GNU_RELRO`
segments, and used it to dynamically verify that the loader calls
protects both segments. We proved
this via a shell script that checks for segfaults when the binary
attempts to illegally write to either protected segment.
Is this something that can be useful for the glibc test suite if
cleaned up? Or would you prefer to hold
off on this glibc patch entirely until explicit linker support is landed?
More information about the Libc-alpha
mailing list