llvm dev - Nov 2019 - RFC: Loadable segments watermark for lld

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191121/3a8a52f9/attachment.html>

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>

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.

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.

On Tue, Nov 26, 2019, 10:04 PM Rui Ueyama via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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
>>
> _______________________________________________
> 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/20191126/f6f0fdc2/attachment.html>