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

[Fangrui Song via Phabricator via llvm-commits]

MaskRay added a comment.

In D66426#1768793 <https://reviews.llvm.org/D66426#1768793>, @jhenderson wrote:

> In D66426#1767580 <https://reviews.llvm.org/D66426#1767580>, @MaskRay wrote:
>
> > > The whole point of the watermark is to show that no post-link modifications have been made, and if the watermark itself is added post-link, it does not achieve this aim: someone could either deliberately or accidentally add a step prior to the watermarking happening.
> >
> > I am still confused. What I infer from the sentence is that strip/llvm-strip is still allowed. To make .note.llvm.watermark survive strip/llvm-strip, you place it into a PT_NOTE segment. So post-link modification is still possible, then why can't you use another tool to compute the watermark and append a section? In my comment, there are some other questions that are not answered. I have suggested an approach that will not slow down the whole build time.
>
>
> (For clarity, @chrisjackson and I are on the same team, and I've been helping him with this). The problem with any post-link external tool used to create the watermark is that it doesn't prevent something happening between the link step and the watermarking step. For example, this would not be detected: 1) Do link; 2) Make a modification to the .data section; 3) Run the watermark tool.
>
> Stripping (and other things that don't affect the loadable image) is allowed, because it doesn't affect the loadable image. The aim of the watermark is to detect //loadable// data changes.


As I understand it, the scenario is:

1. Do link; 2) Run the watermark tool to append .note.llvm.watermark; 3) Release SDK; 4) Downstream vendors modify .data and ship to end users; 5) End users verify that .note.llvm.watermark does not match computed watermark of loadable contents.

The build process before 3) are all controlled. The process should ensure there is no modification to .data between 1) and 2). How do you guarantee a linker side feature can prevent modification? How can you prevent the following:

1. Do link and generate .note.llvm.watermark in one step 1.5) Modify .data 2) Run the watermark tool to update .note.llvm.watermark

> Build times should include the watermarking process, since that is part of creating a release build (just as e.g. llvm-strip etc should be too). Thus, saying that an external tool will not slow down build times is incorrect.

The watermark tool can append .note.llvm.watermark to the executable. It just has to rewrite the section header table at the end of the ELF (usually a few hundred bytes). This is not slower than a built-in linker feature.

>> In my comment, there are some other questions that are not answered. I have suggested an approach that will not slow down the whole build time.
> 
> I think you are referring to adding this to llvm-objcopy, yes? I think my above point should address this.




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

https://reviews.llvm.org/D66426