<div dir="ltr"><div>From previous reviews I recall that .note.llvm.watermark is a non-SHF_ALLOC section. Linkers normally place non-SHF_ALLOC sections after SHF_ALLOC ones. I think a post-link tool can be used to append .note.llvm.watermark to an ELF file. It just needs to update tens to a few hundred bytes (section header table+content of .note.llvm.watermark), assuming the position of .note.llvm.watermark does not matter.<br></div><div><br></div><div>I feel that the reasoning of building .note.llvm.watermark being an lld feature is not sufficiently strong. Does it need to be fast? (A benchmark measuring the performance will be useful.) .note.llvm.watermark seems to be only used in releases. Releases naturally involve a lot of preparation and verification. I can't imagine that running a post-link tool can be a bottleneck. During development .note.llvm.watermark is probably not very useful.<br></div><div><div><br></div><div>If .note.llvm.watermark is indeed non-SHF_ALLOC, it can be discarded by llvm-objcopy/llvm-strip --strip-all, but not by --strip-all-gnu (objcopy/strip --strip-all). Is this an expected modification?</div></div><div><br></div><div>If we reach the consensus that this section is useful, llvm-objcopy may be the right place to implement the update/verification features. If the performance is really critical (see my question mentioned before), we probably need to make llvm-objcopy's in-place update fast by not overwriting contents that are not changed.</div><div><br></div><div>> <b>Is computing memory-mapped sections strong enough to detect post-link modifications?</b></div><div><b><br></b></div><div>In most cases, yes. A lot of people (including me) hold the opinion that non-SHF_ALLOC parts should not affect runtime execution. There are some counter-examples (runtime introspection), though. 1) The non-SHF_ALLOC .ARM.attributes (<a href="https://reviews.llvm.org/D69188">https://reviews.llvm.org/D69188</a>) is used by Debian patched glibc ld.so. 2) The .ctf developers intend .ctf to be non-strippable <a href="https://sourceware.org/ml/binutils/2019-09/msg00209.html">https://sourceware.org/ml/binutils/2019-09/msg00209.html</a> (see the thread in October; I even implemented objcopy --keep-section for them but I may likely lose the battle).</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 26, 2019 at 11:15 PM Jake Ehrlich 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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" 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"><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" rel="noreferrer" 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">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" rel="noreferrer" target="_blank">https://reviews.llvm.org/D70316</a><br><a href="https://reviews.llvm.org/D66426" rel="noreferrer" target="_blank">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" rel="noreferrer" target="_blank">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" rel="noreferrer" target="_blank">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">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><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">宋方睿</div></div>