[llvm-dev] [RFC] Moving RELRO segment

[Vic (Chun-Ju) Yang via llvm-dev]

Hey all,

TL;DR: Moving RELRO segment to be immediately after read-only segment so
that the dynamic linker has the option to merge the two virtual memory
areas at run time.

This is an RFC for moving RELRO segment. Currently, lld orders ELF sections
in the following order: R, RX, RWX, RW, and RW contains RELRO. At run time,
after RELRO is write-protected, we'd have VMAs in the order of: R, RX, RWX,
R (RELRO), RW. I'd like to propose that we move RELRO to be immediately
after the read-only sections, so that the order of VMAs become: R, R
(RELRO), RX, RWX, RW, and the dynamic linker would have the option to merge
the two read-only VMAs to reduce bookkeeping costs.

While I only tested this proposal on an ARM64 Android platform, the same
optimization should be applicable to other platforms as well. My test
showed an overall ~1MB decrease in kernel slab memory usage on
vm_area_struct, with about 150 processes running. For this to work, I had
to modify the dynamic linker:
  1. The dynamic linker needs to make the read-only VMA briefly writable in
order for it to have the same VM flags with the RELRO VMA so that they can
be merged. Specifically VM_ACCOUNT is set when a VMA is made writable.
  2. The cross-DSO CFI implementation in Android dynamic linker currently
assumes __cfi_check is at a lower address than all CFI targets, so CFI
check fails when RELRO is moved to below text section. After I added
support for CFI targets below __cfi_check, I don't see CFI failures anymore.
One drawback that comes with this change is that the number of LOAD
segments increases by one for DSOs with anything other than those in RELRO
in its RW LOAD segment.

This would be a somewhat tedious change (especially the part about having
to update all the unit tests), but the benefit is pretty good, especially
considering the kernel slab memory is not swappable/evictable. Please let
me know your thoughts!

Thanks,
Vic
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190828/b91b0827/attachment.html>