Re: [RFC] ld: Add random filling for unspecified section contents

[Andrew Burgess <andrew dot burgess at embecosm dot com>]

* Petr Ovtchenkov <ptr@void-ptr.info> [2017-05-16 10:24:11 +0300]:

> Good day,
> 
> On Mon, 15 May 2017 17:43:00 +0100
> Nick Clifton <nickc@redhat.com> wrote:
> 
> > 
> > > Do you consider pros/contras for "Add random filling for unspecified section contents",
> > > in particular with relation to "Reproducible Builds" issue?
> > 
> > Part of the proposal did include a new linker command line option to set
> > the seed for random number generation, so that reproducible, random 
> > contents would be generated.
> 
> Reproducible pseudo-random filling? Hmm, is any sense in this?

I feel compelled to write a small defence of the patch, even though I
consider the issue indefinitely on-hold....for now.

Obviously in the intended use case reproducibility was not critical,
though even that would have been fine (see below), I added that
feature specifically so that anyone who was stuck with a script that
included random fill could still achieve reproducible builds (though
this would loose some of the randomness) without having to change any
of the program source (and I include the linker script as source).

The primary goal for the patch was to avoid filling between input
sections, and after input sections with an obvious pattern (all zero,
or some other easy to spot pattern).  Actually, if a particular
product build always created the same pseudo-random sequence then that
would be fine.

As Nick pointed out, within the context of an ELF random fill doesn't
really offer much, but my interest is more for targets where the
section contents are extracted from the ELF and flashed onto embeded
devices.

Nick also pointed out (and this is what I originally hacked together
before I put forward this patch) that we can parse the linker map file
and use this to retroactively overwrite the fill with random data
afterwards.  It's not nice, but it works, at least until I can find a
suitable bribe to slip to Nick ;-)

Thanks,
Andrew