<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, May 17, 2017 at 1:32 PM, Rui Ueyama via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-">On Wed, May 17, 2017 at 1:11 PM, Petr Hosek <span dir="ltr"><<a href="mailto:phosek@chromium.org" target="_blank">phosek@chromium.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>The motivation is not only memory savings but also security: can-never-be-written is strictly better than RELRO in all cases. The biggest win is when .dynamic is the sole reason for having a writable segment at all. The distinction is fairly small for exploitability, but not negligible. </div></div></blockquote><div><br></div></span><div>I'm not even sure if it is strictly better to make .dynamic read-only by default is better than relro. It seems almost the same to me. What are attack scenario you can think of in which you can exploit only when .dynamic sections are read-only from beginning? </div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Maybe Fuchsia OS does something special for executable that contain read-only sections only?</div></div></div></div></blockquote><div><br></div><div> I'd be interested in this as well, CFI relies on relro for its vtable protection to work. Is the issue just the window of opportunity between mapping the pages and protecting them?</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"></div></div></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>LLD already has several command-line options that are not supported by or are different from ld or gold, so this wouldn't be the first one (and probably not the last). If LLD supported per-OS configuration, we would make this default for Fuchsia and wouldn't need the new option, but since these don't exists, it's something we would handle through the Clang driver.</div></div></blockquote><div><br></div></span><div>Yes, we have bunch of options that are not supported by GNU linkers, particularly for LTO. So adding new options is fine as long as doing it makes sense. But the bar should be higher than implementing compatible options. </div><div><br></div><div>Having no host OS-specific default options in the linker is more like a feature than a lack of a feature. We rely on compilers to give appropriate options to us. That makes the linker's behavior more predictable, and it also makes it very easy to support cross-linking.</div></div></div></div></blockquote><div><br></div><div>Note that you could avoid needing to add a new flag by defining a new ELFOSABI for Fuchsia and making this behaviour conditional on it.</div><div><br></div><div>Peter</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="gmail-h5"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div class="gmail-m_7407955602691031360h5"><div class="gmail_quote"><div dir="ltr">On Tue, May 16, 2017 at 7:12 PM Rui Ueyama via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.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"><div dir="ltr">Thank you for confirming. But one page is too small, no? I think we are not that picky about memory footprint. For example, LLD and gold's outputs are usually slightly different in size due to various reasons such as the differences how they order sections, common symbols, etc., but no one seems to care about that kind of negligible differences. Merging DT_MIPS_RLD_MAP into DT_DEBUG_INDIRECT seems like a good change, but adding a new command option to save one page at runtime seems overkill to me. (But I don't know much about Fuchsia, so correct me if I'm wrong.)</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 16, 2017 at 6:08 PM, Jake Ehrlich via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>Your understanding is correct. It saves a small number of physical pages. It's strictly better even if it's only a little bit better.</span><div class="gmail-m_7407955602691031360m_3362128820812895302m_1755940200545071832HOEnZb"><div class="gmail-m_7407955602691031360m_3362128820812895302m_1755940200545071832h5"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, May 16, 2017, 5:14 PM Rui Ueyama <<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</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"><div dir="ltr">Hi Jake,<div><br></div><div>Thank you for sending this to llvm-dev!</div><div><br></div><div>If I understand correctly, your motivation to add an option to make .dynamic sections read-only is to share .dynamic sections in memory so that each process executing the same file doesn't have to have a separate copy of a .dynamic section. But you would usually save just one page or two by doing that because .dynamic sections are usually very small. Even if they are large, they could be shared between processes by copy-on-write. What am I missing?</div></div><div class="gmail_extra"><br><div class="gmail_quote"></div></div><div class="gmail_extra"><div class="gmail_quote">On Tue, May 16, 2017 at 4:31 PM, Jake Ehrlich via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>This is a proposal to add an option to lld that forces .dynamic sections to be read-only. </div><div><br></div><div><span style="color:rgb(33,33,33);font-size:13px">The .dynamic section is almost read-only except for the DT_DEBUG entry which requires the dynamic linker to modify a word. MIPS has long since had a solution to this using the DT_MIPS_RLD_MAP entry to give a pointer to another section which is writable. It would be nice to have this functionality on other targets as well however. Right now many dynamic linkers do not support this layer of indirection so this can't happen by default, it must be an option. Currently .dynamic gets mapped to a PT_GNU_RELRO section. PT_GNU_RELRO sections are not shared between instances of a executable however. It would be a nice optimization to share the .dynamic section of an application where possible. In particular we would like to have this option for Fuchsia. Other dynamic linkers, like musl, already have some support for this on non-MIPS targets as seen here: </span><a href="http://git.musl-libc.org/cgit/musl/tree/ldso/dynlink.c#n1629" style="font-size:13px" target="_blank">http://git.musl-libc.org<wbr>/cgit/musl/tree/ldso/dynlink.<wbr>c#n1629</a><span style="color:rgb(33,33,33);font-size:13px">. In particular the DT_DEBUG_INDIRECT entry is recognized.</span><br><br>This change would refactor code that already exists for MIPS specific .dynamic sections and make them available to other targets. Mostly this would just require renaming some things and moving a few lines around. The biggest part of this change would be to add the flag. I propose it be a -z keyword called "rodynamic".<br><br>I have already made a patch for this change which can be seen here: <a href="https://reviews.llvm.org/D33251" target="_blank">https://reviews.llvm.org<wbr>/D33251</a><br><br>Best,<br>Jake</div></div>
<br></blockquote></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">______________________________<wbr>_________________<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="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div>
</blockquote></div>
</div></div><br>______________________________<wbr>_________________<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="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div>
______________________________<wbr>_________________<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="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div></div></div>
</blockquote></div></div></div><br></div></div>
<br>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">-- <div>Peter</div></div></div>
</div></div>