This is the mail archive of the
mailing list for the binutils project.
Re: [RFC] ld: Add random filling for unspecified section contents
- From: Nick Clifton <nickc at redhat dot com>
- To: Andrew Burgess <andrew dot burgess at embecosm dot com>, binutils at sourceware dot org
- Date: Thu, 20 Apr 2017 14:43:06 +0100
- Subject: Re: [RFC] ld: Add random filling for unspecified section contents
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=nickc at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 42D8FC0467F2
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 42D8FC0467F2
- References: <firstname.lastname@example.org>
> I'd like to propose the following feature, the ability for the linker
> to randomise the fill data within a section (right now we can only
> provide a fixed fill pattern).
> One use case for such a feature would be to pad out a data section
> while making it slightly harder for someone else examining the object
> file to determine which parts of the section are actual content, and
> which parts are padding.
I have to say that I do not think there will be much real gain from this
feature. Surely an attacker can examine the symbol table to determine
the last addressed point in a padded data section and use that as a guide
to what is real data and what is padding.
> At the moment I'm using jrand48, this isn't thread-safe, but does take
> it's seed as an argument for each call.
What about using jrand48_r instead ?
> The problem is that I'm pretty sure this function is not available on
> every platform we target, and I'm not sure what the right thing to use
> instead is.
Write a configure check for the function and only use it if available ?
> I'm wondering if the right thing to do is to add a reentrant random
> number API to libiberty and use that. However, I'm open to any
> suggestions for what the right thing to do might be.
How about using random(), setstate() and initstate() - all provided by
libiberty ? That should provide wider availability, although not thread