[llvm-dev] RFC: Loadable segments watermark for lld

[Rui Ueyama via llvm-dev]

Hi Chris,

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
modifications?*

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
> loadable
> segments and places the result in a note section. Ongoing work can be found
> here:
>
> https://reviews.llvm.org/D70316
> https://reviews.llvm.org/D66426
>
> The purpose of this watermark is to enable detection of post-link
> modifications
> to the loadable segments of the binary. Such modifications may produce a
> binary
> that relies on functionality that is an incidental detail of the OS that
> may
> change in a future update and negatively affect the runtime behaviour of
> the
> binary.
>
> As well as identifying reliance on unspecified behaviour, on detection of
> post-link changes we can then look at improving our tooling to support
> whatever
> 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.
>
> Chris
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191127/4355eb8a/attachment.html>