Re: [PATCH] elf: Support multiple PT_GNU_RELRO segments
Adhemerval Zanella Netto <[email protected]>
| Newsgroups | gmane.comp.lib.glibc.alpha |
|---|---|
| Organization | Linaro |
| Message-ID | <[email protected]> |
On 07/07/26 15:17, Justin Rivera wrote: > On Mon, Jul 6, 2026 at 5:15 PM H.J. Lu <[email protected]> wrote: >> >> On Tue, Jul 7, 2026 at 5:11 AM Justin Rivera <[email protected]> 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.