<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 29, 2019 at 2:42 AM Peter Smith <<a href="mailto:peter.smith@linaro.org">peter.smith@linaro.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello Vic,<br>
<br>
I don't have a lot to add myself. I think that majority of the input<br>
needs to come from the OS stakeholders. My main concern is if it<br>
requires work on every platform to take advantage or avoid regressions<br>
then perhaps it is worth adding as an option rather than changing the<br>
default. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Some questions:<br>
- Does this need work in every OS for correctness of programs? For<br>
example you mention that cross-DSO CFI implementation in Android<br>
needed to be updated, could that also be the case on other platforms?<br></blockquote><div>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: <a href="https://clang.llvm.org/docs/ControlFlowIntegrityDesign.html#cfi-shadow">https://clang.llvm.org/docs/ControlFlowIntegrityDesign.html#cfi-shadow</a>. Either those implementations need to be fixed or we need to add an option for where RELRO is placed (which brings more maintenance cost).</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- Does this need work in every OS to take advantage of it? For example<br>
would this need a ld.so change on Linux?<br></blockquote><div>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.)</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The last time we updated the position of RELRO was in<br>
<a href="https://reviews.llvm.org/D56828" rel="noreferrer" target="_blank">https://reviews.llvm.org/D56828</a> it will be worth going through the<br>
arguments in there to see if there is anything that triggers any<br>
thoughts.<br></blockquote><div>Thanks for the pointer! I'll go through it.</div><div><br></div><div>Vic </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Peter<br>
<br>
On Thu, 29 Aug 2019 at 09:22, Rui Ueyama <<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>> wrote:<br>
><br>
> Hi Vic,<br>
><br>
> 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.<br>
><br>
> On Thu, Aug 29, 2019 at 2:51 PM Vic (Chun-Ju) Yang via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
>><br>
>> Hey all,<br>
>><br>
>> 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.<br>
>><br>
>> 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.<br>
>><br>
>> 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:<br>
>>   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.<br>
>>   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.<br>
>> 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.<br>
>><br>
>> 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!<br>
>><br>
>> Thanks,<br>
>> Vic<br>
>><br>
>> _______________________________________________<br>
>> LLVM Developers mailing list<br>
>> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
>> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>