MarcZX10 found that this branch's RELRO fix doesn't hold when the
original image has more than one disjoint PT_SCE_RELRO range: ElfReader
retypes each one into its own PT_GNU_RELRO header, but glibc's loader
only tracks one PT_GNU_RELRO segment per image, so a later entry
silently overwrites the earlier one in the loader's state and only the
last range actually ends up protected. LLD's own linker has the same
one-segment assumption. Widening a single range to span the gap
between them isn't a safe fix either, since it would also protect
memory that was never part of any RELRO range.
Until a title is found that actually needs more than one disjoint
range, the program header layout builder now throws a clear error
instead of silently protecting only one of them.
Tested: two new program_layout_ranges cases (a single RELRO range
still reserves its header slot; two disjoint ranges are rejected).
Full relinker-only ctest suite: 245/246 pass, the one failure
(input_magic) is the same pre-existing, unrelated ASan allocation
issue seen on this branch before this change. Verified by hand with a
real two-range fixture converted through the actual relinker binary:
the Linux target now exits 2 with a clear message and writes no
output file, instead of silently succeeding with only one range
protected. check_conventions.py and git diff --check both pass.
Outputs whose input carries no PT_GNU_STACK get one appended with
PF_R|PF_W and alignment 16 so the kernel does not fall back to an
executable stack marking.
RequiredProgramHeaderCount and WriteLayout now derive from one shared
header list, so the reserved slot and the written header cannot
disagree at any PhNum boundary, when a free input slot should be
reused, or when the RELRO coverage guard reduces the kept count.
Space exhaustion beyond the 16-bit header limit fails loudly instead
of silently skipping the header.
ComputeExtraBlockVaddr kept the ELF congruence p_vaddr == p_offset (mod 0x1000)
and bumped the result by one page only when it fell below the highest guest
load end as a byte address. When that end is not page aligned and the extra
block's file offset remainder reaches it, the extra RWX PT_LOAD landed in the
same 4 KiB page that holds the tail of the highest guest segment. The kernel
maps each PT_LOAD page by page with MAP_FIXED in program-header order, so the
extra block's file page replaced the guest's .data tail and zero-filled .bss
there.
Round the highest kept PT_LOAD end up to the page before adding the offset
remainder, which is the placement GuestModuleWriter::WriteLinux already uses
for the guest module. Only the overlapping case changes; an end that is page
aligned or a remainder below it yields the same address as before.
The extra PT_LOAD now also spans to the end of its own page in p_memsz, so the
page it takes over is fully covered, and its vaddr is derived in WriteLayout
instead of being taken from the request. The header block load carries the
same flags as before.
shurhundo