[PATCH] D66426: [lld] Enable a watermark of loadable sections to be generated and placed in a note section

[Chris Jackson via Phabricator via llvm-commits]

chrisjackson added a comment.

In D66426#1664254 <https://reviews.llvm.org/D66426#1664254>, @ruiu wrote:

> It seems the main reason why you guys wanted to avoid an external tool is that it is too easy to forget to run the tool after link. But that can be fixed easily by writing a shell script as ld.lld which invokes the real ld.lld and a watermarking tool. Or, you could make a change to lld so that, after creating an executable file and before existing, lld invokes a watermarking tool on a file that the linker just created (in this configuration, the watermarking tool can either run in the same process or as a child process). Have you considered that approach? I think it is fine to add this feature directly to lld if it is convenient, but I'd like to explore other possibilities before we make a decision.
>
> Besides that, there are a few technical concerns in this patch as below:
>
> - lld guarantees that the same build id will be computed only when the resulting output file (except the build id part itself) and the linker version are the same. We didn't guarantee that different versions of lld compute the build id in the same way. Actually, we have tweaked hash functions and the strategy for tree hash several times. This contract seems too weak for your use case -- for your use case, we need to guarantee that the way how we compute a hash value doesn't change over time. So, we need to make sure that the current way of hash computation is something that we want to maintain like forever.
>
>   If watermarking doesn't have to be fast (e.g. users only have to do this for release binaries), consider using a simple non-tree hash function.
> - Maybe you should add a version field or something to the note section so that we can change a hash function or something in the future.
> - The watermark feature is to make sure that the program image loaded to memory hasn't changed since its file is created. In that sense, the hash function seems a bit too fragile. If you move a segment within an ELF file, you'd have to change the file offset field of a program header, but the memory image won't change by doing that, so in the sense of watermarking, I don't think it should be considered a change.


Unfortunately the shell available is not particularly capable and because performance is critical we are reluctant to pay the penalty for invocation of an external tool in this way. However, we are going to experiment with invoking a process with lld directly and examine the performance differences.

Of course we would like to maintain the watermark between versions of lld, so we will decouple the buildId and watermark functionality. The inclusion of a version in the note is a good idea should changes be needed in future.

Indeed the order of segments within the ELF file could change without affecting the image loaded to memory. We will modify the watermark computation so that it is agnostic to this ordering.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D66426/new/

https://reviews.llvm.org/D66426