[PATCH] elf: Support multiple PT_GNU_RELRO segments
H.J. Lu
hjl.tools@gmail.com
Tue Jul 7 23:37:02 GMT 2026
On Wed, Jul 8, 2026 at 3:52 AM Adhemerval Zanella Netto
<adhemerval.zanella@linaro.org> wrote:
>
>
>
> On 07/07/26 15:17, Justin Rivera wrote:
> > 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?
>
> We already have scripts/tst-elf-edit.py which creates synthetic DSO with
> different alignments, so a platform agnostic testing framework could work.
>
> Is these hand-written assembly arch-specific or can you make them generic
> (so we can test onany supported ABI)?
>
> One possibility is to create the tests (ET_EXEC/ET_DYN) with some extra dummy
> DT_NEEDED tags by linking with -Wl,--as-needed and some libraries, and then
> post-processing it and replace it with PT_GNU_RELRO tags.
>
> The mold linker has --spare-dynamic-tags=N, but unfortunately we can not rely
> on it for testing.
>
ld has
‘--spare-dynamic-tags=COUNT’
This option specifies the number of empty slots to leave in the
.dynamic section of ELF shared objects. Empty slots may be needed
by post processing tools, such as the prelinker. The default is 5.
--
H.J.
More information about the Libc-alpha
mailing list