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

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

* Nick Clifton <nickc@redhat.com> [2017-05-05 10:39:26 +0100]:

> Hi Andrew,
> 
> > The situation in which I'm making use of this feature is really
> > outside of the ELF.  I'm linking code for an embeded target where
> > the code/data that is eventually loaded onto the device is extracted
> > from the ELF, so there's no symbol table, of section/segment table to
> > reveal any information.
> 
> But if the data is being extracted from an ELF file, why can't the 
> extraction tool add in random data to pad out the rest of the data
> section ?  It has the ELF headers available, so it must know the size
> of the section.  [Basically I am trying to argue the case for not
> adding a feature to the linker if it is not really necessary].  This
> would also have the advantage that the enhanced extraction tool would
> work with binaries produced by other linkers, or older versions of GNU
> ld.

That's exactly what I do at the moment.  This patch was just an
attempt to fold the feature into the linker as it seemed like a fairly
small extension which others might have found helpful (for
embeded/security targets).







> 
> 
> >> What about using jrand48_r instead ?
> > 
> > That I suspect will suffer from the same issue of unavailability on
> > some targets.  The particular target that I know about would be Mingw
> > (that is a target we support, right?)
> 
> Right.
> 
> > where as far as I can tell /
> > figure out, there are very few random APIs available.  I don't
> > directly have access to such a target for testing so I'm pretty
> > limited in what I can figure out.
> 
> Hmm, no access to the target, a run-time environment without a full 
> POSIX implementation and brand new linker feature.  What could go wrong ? :-)

Indeed :) But what would life be without a few challenges!

> >>> I'm wondering if the right thing to do is to add a reentrant random
> >>> number API to libiberty and use that.
> 
> Have you tried asking the libiberty maintainers about this ?  It does
> sound like something that they might find worthwhile.
> 
> 
> > I originally avoided that as it seemed a little clunky, but, I suspect
> > my only other option is writing a jrand48_r like thing in libiberty
> > (which I'd rather avoid), so I've taken your suggestion and switched
> > to a random/setstate/initstate solution.
> > 
> > Would you be OK with this in tree?
> 
> Well, I am still reluctant, on the grounds that it is adding a new feature
> with a very limited use-set.  One thing that did occur to me however, was -
> is it possible to use a linker plugin to achieve the desired effect ?  I
> am just asking off the top of my head here, I have not actually checked to
> see if it would be possible, but it would certainly avoid the feature-bloat
> issue that I am worried about.  (FYI - I know that the plugin could not add
> a new keyword to the linker script parser, but it might be able to add in
> its own padding to data sections as they are read in, or linked, or it might
> be able to overwrite the FILLed in data sections after they have been placed
> into the linker map).

OK, it doesn't sound like I'm going to convince you, so I'll park this
patch for now.  I appreciate the suggestions, but as I said above, I
already have an out-of-linker solution for this problem, I was trying
to move it in linker as it felt like a nice extension to the existing
fill support.

Thanks for taking the time to review this,

Andrew