[llvm-dev] [RFC] Moving RELRO segment

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

On Thu, Aug 29, 2019 at 2:42 AM Peter Smith <peter.smith at linaro.org> wrote:

> Hello Vic,
>
> I don't have a lot to add myself. I think that majority of the input
> needs to come from the OS stakeholders. My main concern is if it
> requires work on every platform to take advantage or avoid regressions
> then perhaps it is worth adding as an option rather than changing the
> default.


> Some questions:
> - Does this need work in every OS for correctness of programs? For
> example you mention that cross-DSO CFI implementation in Android
> needed to be updated, could that also be the case on other platforms?
>
Indeed this could be a problem for other platforms. I'm not familiar with
what CFI implementations are commonly in use, but from what I can tell, the
implementation mentioned in Clang CFI design doc has this problem as well,
so I wouldn't be surprised that we see this problem in other
implementations:
https://clang.llvm.org/docs/ControlFlowIntegrityDesign.html#cfi-shadow.
Either those implementations need to be fixed or we need to add an option
for where RELRO is placed (which brings more maintenance cost).

> - Does this need work in every OS to take advantage of it? For example
> would this need a ld.so change on Linux?
>
I can't say for sure for other platforms, but for Linux, I think it depends
on how we implement this. If we still keep RO and RELRO segments separate,
ld.so needs to be updated for the VM_ACCOUNT issue I mentioned in order to
take advantage of this. However, we can consider merging RO segment into
RELRO segment if they are adjacent to each other (i.e. make what's RO now a
part of RELRO), so that we have one less LOAD and also existing linkers can
take advantage of this without change (well, except for the CFI issue.)

>
> The last time we updated the position of RELRO was in
> https://reviews.llvm.org/D56828 it will be worth going through the
> arguments in there to see if there is anything that triggers any
> thoughts.
>
Thanks for the pointer! I'll go through it.

Vic

>
> Peter
>
> On Thu, 29 Aug 2019 at 09:22, Rui Ueyama <ruiu at google.com> wrote:
> >
> > Hi Vic,
> >
> > I'm in favor of this proposal. Saving that amount of kernel memory by
> changing the memory layout seems like a win. I believe that there are
> programs in the wild that assume some specific segment order, and moving
> the RELRO segment might break some of them, but looks like it's worth the
> risk.
> >
> > On Thu, Aug 29, 2019 at 2:51 PM Vic (Chun-Ju) Yang via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >>
> >> 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
> >>
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> llvm-dev at lists.llvm.org
> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190829/3198fed7/attachment.html>