Re: Patch: Initialise new file space to zero for Beos

[Ian Lance Taylor <ian at zembu dot com>]

   From: fnf@toadfish.ninemoons.com
   Date: Mon, 20 Sep 1999 06:46:29 -0700 (MST)

   If this function is called everytime gcc, gas, ld, etc wants to do an
   fseek of any kind, then there will be at least two ftell calls and one
   fseek before the actual seek that needs to be done.

As a practical matter, most calls to fseek in the binutils already go
through bfd_seek, so the performance impact of changing fseek compared
to changing bfd_seek should be fairly minimal.  For most targets, gcc
never calls fseek at all.

Unix defines a certain model of file I/O: if you seek past the end of
a file, the blocks you skipped will be read as zeroes.  Expecting this
to be the case is not unique to the binutils.  I think it is
inappropriate to patch bfd_seek specifically to solve a general
problem which can afflict any Unix program.  The binutils are not the
only program which expect this type of file I/O to succeed.

   As far as I know, part of the reason that BeOS does not zero the new
   blocks added to a file by seeking past the end of it is that we wish
   to avoid the performance overhead (small as it might be) of always
   zeroing space that is probably going to be simply overwritten anyway.

I would think that the performance overhead would be very close to
zero if you can do the test within the kernel.  And, as you say, it's
an exploitable security hole.  But it's not my call.

   Note that the only bug we have observed in the tools to date is the
   assembler writing random data to parts of object files that are
   allocated by seeking past the current end of the file and then never
   overwritten with "real data".

For BFD, I believe that this is the only bug you will observe.  BFD
will always write any data which any program is expected to read; that
is, it does not optimize for skipping zeroes.  Object file formats are
defined such that some bytes are never read, and BFD generally will
not write those bytes.

Ian