Re: Question about binfmt_elf.c

[Roland McGrath <roland@redhat.com>]

> On Fri, 16 Jul 2010 15:12:39 -0500
> Rob Landley <rob@landley.net> wrote:
> 
> > Could somebody please update this comment to explain why fiddling with 
> > strangely protected bss is _not_ an easy way to leak arbitrary amounts of 
> > uninitalized kernel memory (with whatever previous contents they have) to 
> > userspace?

I can't tell why you would ever think that was possible.  There is no
kernel memory involved, uninitialized or otherwise.  All the memory in
the user address space is "initialized", being either zero pages or
file-mapped pages.  The only thing that happens when bogus ELF headers
prevent us from clearing some bss is that a partial page of file data
is visible in user memory rather than being all zero.

> In January 2005 davem added a check.  In Feb 2005 Pavel said "hey, my
> Kylix application broke".  So we took the check out again.
> 
> http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg60120.html
> http://www.mail-archive.com/bk-commits-head@vger.kernel.org/msg01390.html

Note there are other places that call padzero() and do check its
result.  So we're only ignoring the error for one particular kind of
bss, which is not even done in normal layouts at all (with the right
p_flags or not).  Usually, there is only bss in the last segment, which
is the path that uses padzero().  This code path without the error
check is only used for a segment that both has bss (p_memsz > p_filesz)
and is followed by some other PT_LOAD segment.

> I don't kow how one would craft such an elf file.  

  $ cat badbss.lds
  SECTIONS {
	  . = SIZEOF_HEADERS;
	  .text : { *(.text*) } :re
	  .bss : { *(.bss*) } :re
	  . = ALIGN(0x1000);
	  .data : { *(.data*) } :rw
  }

  PHDRS {
	  re PT_LOAD FLAGS(5) FILEHDR PHDRS;
	  rw PT_LOAD FLAGS(6);
  }
  $ gcc -m32 -static -nostdlib -nostartfiles -o badbss -xc <(echo 'char use_bss[0x234], use_data[0x345]={1,}; _start(){}') -Wl,badbss.lds
  $ eu-readelf -l badbss
  Program Headers:
    Type           Offset   VirtAddr   PhysAddr   FileSiz  MemSiz   Flg Align
    LOAD           0x000000 0x08048000 0x08048000 0x00009d 0x001634 R E 0x1000
    LOAD           0x0000a0 0x080490a0 0x080490a0 0x000345 0x000345 RW  0x1000

   Section to Segment mapping:
    Segment Sections...
     00      [RO: .note.gnu.build-id .text .data .bss]
     01      [RO: .data]

To the loader, "bss" means p_memsz > p_filesz, as you see there in the
first LOAD segment.  And it's not writable.


Thanks,
Roland