[llvm-dev] RFC: Loadable segments watermark for lld
Rui Ueyama via llvm-dev
llvm-dev at lists.llvm.org
Tue Nov 26 22:03:38 PST 2019
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):
*Why build-id is not sufficient?*
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.
*What kind of post-link modification are you expecting?*
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?
*Is computing memory-mapped sections strong enough to detect post-link
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.
On Thu, Nov 21, 2019 at 8:43 PM Chris Jackson via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hello all,
> I'm implementing a watermarking feature for lld that computes a hash of
> segments and places the result in a note section. Ongoing work can be found
> The purpose of this watermark is to enable detection of post-link
> to the loadable segments of the binary. Such modifications may produce a
> that relies on functionality that is an incidental detail of the OS that
> change in a future update and negatively affect the runtime behaviour of
> As well as identifying reliance on unspecified behaviour, on detection of
> post-link changes we can then look at improving our tooling to support
> changes had been applied.
> Its critical for us that the watermark has minimal impact on build time and
> cryptographic security is not the goal. Hence, xxhash is used as our
> experiments showed it has minimal overhead.
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev