Patch to eliminate garbage in DJGPP execs

Patch to eliminate garbage in DJGPP execs

[Mark E.]

Hello once again,

First, thanks to DJ and Nick for handling my barrage of patches over the last several 
days. This one should be the last for a little while barring any last minute 
developments.

In DJGPP executables, the area between the end of the section headers and the start of 
the first section's data (typically the .text section's) contains garbage. This garbage 
is what was already there when the space was allocated on the disk. It's there because 
the operating system doesn't blank the space out when seeking past EOF, like the object 
file output routine does. This presents an obvious security risk if you distribute this 
executable. The patch below blanks out this area for DJGPP-specific targets to 
eliminate this risk.

bfd/Changelog:

2000-06-30  Mark Elbrecht  <snowball3@bigfoot.com>

	* coff-go32.c (coff_write_object_scnhdrs_post): New function.
	* coff-stgo32.c (coff_write_object_scnhdrs_post): Likewise.
	* coff-go32.c (COFF_WRITE_OBJECT_SCNHDRS_POST): Define.
	* coffcode.h (coff_write_object_contents): Use it if defined.
	* coff-stgo32.c (COFF_WRITE_OBJECT_SCNHDRS_POST): Define.
	* coff-go32.c: Include bfd.h.

Index: src/bfd/coff-go32.c
===================================================================
RCS file: /cvs/src/src/bfd/coff-go32.c,v
retrieving revision 1.5
diff -c -p -r1.5 coff-go32.c
*** coff-go32.c	2000/05/03 04:25:33	1.5
--- coff-go32.c	2000/07/01 00:37:52
*************** Foundation, Inc., 59 Temple Place - Suit
*** 38,41 ****
--- 38,75 ----
  { COFF_SECTION_NAME_PARTIAL_MATCH (".gnu.linkonce.r"), \
    COFF_ALIGNMENT_FIELD_EMPTY, COFF_ALIGNMENT_FIELD_EMPTY, 4 }
  
+ #include "bfd.h"
+ 
+ static void
+ coff_write_object_scnhdrs_post PARAMS ((bfd *));
+ 
+ #define COFF_WRITE_OBJECT_SCNHDRS_POST coff_write_object_scnhdrs_post
+   
  #include "coff-i386.c"
+ 
+ /* Fill the gap between the end of the section headers and the start
+    start of the first section's contents if creating an executable.
+    This is needed for certain operating systems that do not blank the
+    space created by seeking a file past EOF.  */
+      
+ static void
+ coff_write_object_scnhdrs_post (abfd)
+      bfd * abfd;
+ {
+   if (abfd->flags & EXEC_P)
+     {
+       long curpos = bfd_tell (abfd);
+       long filepos = abfd->sections->filepos;
+       long fill_size = filepos - curpos;
+     
+       if (fill_size > 0)
+         {
+           bfd_byte *b = bfd_zmalloc (fill_size);
+           if (b)
+             {
+               bfd_write ((PTR)b, 1, fill_size, abfd);
+               free (b);
+             }
+         }
+     }
+ }
Index: src/bfd/coff-stgo32.c
===================================================================
RCS file: /cvs/src/src/bfd/coff-stgo32.c,v
retrieving revision 1.6
diff -c -p -r1.6 coff-stgo32.c
*** coff-stgo32.c	2000/05/03 04:25:33	1.6
--- coff-stgo32.c	2000/07/01 00:38:01
*************** static boolean
*** 104,109 ****
--- 104,114 ----
  
  #define coff_bfd_copy_private_bfd_data go32_stubbed_coff_bfd_copy_private_bfd_data
  
+ static void
+ coff_write_object_scnhdrs_post PARAMS ((bfd *));
+ 
+ #define COFF_WRITE_OBJECT_SCNHDRS_POST coff_write_object_scnhdrs_post
+   
  #include "coff-i386.c"
  
  /* I hold in the usrdata the stub */
*************** go32_stubbed_coff_bfd_copy_private_bfd_d
*** 419,422 ****
--- 424,454 ----
    memcpy (bfd_coff_go32stub (obfd), bfd_coff_go32stub (ibfd), STUBSIZE);
  
    return true;
+ }
+ 
+ /* Fill the gap between the end of the section headers and the start
+    start of the first section's contents if creating an executable.
+    This is needed for those operating systems that do not blank the
+    space created by seeking a file past EOF.  */
+      
+ static void
+ coff_write_object_scnhdrs_post (abfd)
+      bfd * abfd;
+ {
+   if (abfd->flags & EXEC_P)
+     {
+       long curpos = bfd_tell (abfd);
+       long filepos = abfd->sections->filepos;
+       long fill_size = filepos - curpos;
+     
+       if (fill_size > 0)
+         {
+           bfd_byte *b = bfd_zmalloc (fill_size);
+           if (b)
+             {
+               bfd_write ((PTR)b, 1, fill_size, abfd);
+               free (b);
+             }
+         }
+     }
  }
Index: src/bfd/coffcode.h
===================================================================
RCS file: /cvs/src/src/bfd/coffcode.h,v
retrieving revision 1.44
diff -c -p -r1.44 coffcode.h
*** coffcode.h	2000/06/19 01:22:37	1.44
--- coffcode.h	2000/07/01 00:43:04
*************** coff_write_object_contents (abfd)
*** 3523,3528 ****
--- 3523,3534 ----
      }
  #endif
  
+ /* Perform target dependant code when neccessary
+    after writing out the section headers.  */
+ #ifdef COFF_WRITE_OBJECT_SCNHDRS_POST
+ COFF_WRITE_OBJECT_SCNHDRS_POST (abfd);
+ #endif
+ 
    /* OK, now set up the filehdr... */
  
    /* Don't include the internal abs section in the section count */

Re: Patch to eliminate garbage in DJGPP execs

[DJ Delorie]

> In DJGPP executables, the area between the end of the section
> headers and the start of the first section's data (typically the
> .text section's) contains garbage. This garbage is what was already
> there when the space was allocated on the disk. It's there because
> the operating system doesn't blank the space out when seeking past
> EOF, like the object file output routine does. This presents an
> obvious security risk if you distribute this executable. The patch
> below blanks out this area for DJGPP-specific targets to eliminate
> this risk.

Other targets, like MinGW, have this problem too, and it's not limited
to that one spot in the file.  A generic fix was suggested for
bfd_seek at one point, I don't remember what happened to it.  I'd
prefer such a fix to something platform-specific.  I can provide some
hints based on fixing this problem in cygwin's lseek() (djgpp probably
should have a similar fix to its lseek also).

Basically:

When you seek, set a flag.  When you write to the file, check and
reset the flag.  If it was set, see if we've seeked past EOF and use
write to extend the file with zeros.  Some cacheing of where bfd
thinks EOF is might be needed for robustness.

This limits the extra check (tell can be expensive) to *only*
write-after-seek cases.

Re: Patch to eliminate garbage in DJGPP execs

[Alan Modra]

On Sat, 1 Jul 2000, DJ Delorie wrote:

> to that one spot in the file.  A generic fix was suggested for
> bfd_seek at one point, I don't remember what happened to it.  I'd

http://sourceware.cygnus.com/ml/binutils/1999-q3/msg00681.html

-- 
Linuxcare.  Support for the Revolution.

Re: Patch to eliminate garbage in DJGPP execs

[Mark E.]

Well, I've managed to find a partial solution to the garbage. I can change 
the linker script like from:
  .text  0x1000+SIZEOF_HEADERS : {
/* .text section contents here.  */
  }

to
  .text 0x1000+SIZEOF_HEADERS : {
 /* .text section contents here.  */
  } = 0

with the same change to .data and this eliminates the garbage between 
sections (as far as I can tell anyway). Then, I went for the gold and tried 
to eliminate the garbage from between the headers and the .text section, but 
it wouldn't work. Here's the attempted change I made:

  .text SIZEOF_HEADERS : {
  . += 0x1000
 /* .text section contents here.  */
  } = 0

This didn't work because the .text section still started at the same place so 
still had that garbage, and then added 0x1000 fill bytes to the start of 
section except of course in the wrong place.

Is there anyway I can convince the linker to put the .text section where I 
want it or have I gone as far as I can here?

Mark