<div dir="auto">The ELF file header isn't always covered by a segment but still affects loading. I think everything else that effects loading/dynamic linking is always covered by a PT_LOAD segment. As evidence this is basically what --strip-sections in llvm-strip and eu-strip do and they produce perfectly runnable binaries.<div dir="auto"><br></div><div dir="auto">Having a hash of the actual memory map is interesting IMO. Build IDs can't really be verified but a hash of the memory map would be loadable with the expected semantics if and only if the hash was verifiable. So if there's a use case for verification, then this seems sensible to me. I'm not sure where such a verification matters however.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 26, 2019, 10:04 PM Rui Ueyama via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</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>Hi Chris,</div><div><br></div><div>Thank you for starting the thread! To make things clear what the proposed feature can or can't do, let me ask a few questions (allow me to ask duplicate questions that were discussed in the review thread):</div><div><br></div><div><b>Why build-id is not sufficient?</b></div><div><br></div><div>If you pass -build-id to the linker, the linker computes a hash of an entire output file and append it to a .note section. This is not intended to be a checksum but more like just a unique identifier. But you might be able to use it as a checksum and detect any post-link modification by recomputing build-id and compare it with the content of a .note section.</div><div><br></div><div><b>What kind of post-link modification are you expecting?</b></div><div><br></div><div>The first thing that comes to mind is strip command which removes debug info and symbol table. But it looks like you are expecting more than that?</div><div><br></div><div><b>Is computing memory-mapped sections strong enough to detect post-link modifications?</b></div><div><br></div><div>I wonder if there's some section or an ELF header field that does not mapped to memory at run-time but affects how the loader works. If such a thing exists, computing a hash of all memory-mapped sections is not enough to catch post-link modifications.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 21, 2019 at 8:43 PM Chris Jackson via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">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">Hello all,<br><br>I'm implementing a watermarking feature for lld that computes a hash of loadable<br>segments and places the result in a note section. Ongoing work can be found<br>here:<br><br><a href="https://reviews.llvm.org/D70316" target="_blank" rel="noreferrer">https://reviews.llvm.org/D70316</a><br><a href="https://reviews.llvm.org/D66426" target="_blank" rel="noreferrer">https://reviews.llvm.org/D66426</a><br><br>The purpose of this watermark is to enable detection of post-link modifications<br>to the loadable segments of the binary. Such modifications may produce a binary<br>that relies on functionality that is an incidental detail of the OS that may<br>change in a future update and negatively affect the runtime behaviour of the<br>binary.<br><br>As well as identifying reliance on unspecified behaviour, on detection of<br>post-link changes we can then look at improving our tooling to support whatever<br>changes had been applied.<br><br>Its critical for us that the watermark has minimal impact on build time and<br>cryptographic security is not the goal. Hence, xxhash is used as our<br>experiments showed it has minimal overhead.<br><br>Chris<br></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>