<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, May 17, 2017 at 1:44 PM Peter Collingbourne <<a href="mailto:peter@pcc.me.uk">peter@pcc.me.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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="m_-6962679642592457382gmail-">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></div></div></blockquote><div><br></div><div>There's one use case we have which is the vDSO. Our kernel has to be able to load this vDSO into every process, but we don't want to include full ELF loader in our kernel, so we use the read-only layout for the vDSO. Combined with page-aligned segments which LLD uses by default, the logic for loading vDSO is trivial. We're considering other use cases as well.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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></div></div></div></blockquote><div><br></div><div>Correct, it eliminates the short window between mapping the page and protecting it. There's also the memory saving; it's only a single page per dynamic library which isn't a lot, by if you multiply that by the number of processes times the number of shared libraries used by these it can become more significant.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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="m_-6962679642592457382gmail-"><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></div></div></blockquote></div></div></div></blockquote><div><br></div><div>One of the design principles we're trying to follow is to make everything read-only, unless it has be writable. The only reason for .dynamic to be writable is DT_DEBUG which is something we never intend to support. FWIW in Fuchsia all we need is a read-only .dynamic without emitting DT_DEBUG altogether, but we wanted to make sure that this flag is also usable elsewhere hence implementing DT_DEBUG_INDIRECT which is already supported by musl as Jake pointed out.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><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"><div class="gmail_extra"><div class="gmail_quote"><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></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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></div></div></blockquote><div><br></div><div>I'd rather have a flag and have our driver set it. ELFOSABI requires driver support which means it becomes difficult to produce Fuchsia binaries with compilers that don't have the right driver (e.g. we have some developers using a combination of GCC with LLD and this would be an issue for them). I'm also not sure how well is ELFOSABI supported with LTO?</div></div></div>