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

[Jake Ehrlich via llvm-dev]

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>