Question about binfmt_elf.c
in [Kernel]
|
Prev: edac: mpc85xx: Add support for new MPCxxx/Pxxxx EDAC controllers
Next: [PATCH 1/4] firewire: cdev: some clarifications to the API documentation
From: Rob Landley on 16 Jul 2010 16:20 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? nbyte = ELF_PAGEOFFSET(elf_bss); if (nbyte) { nbyte = ELF_MIN_ALIGN - nbyte; if (nbyte > elf_brk - elf_bss) nbyte = elf_brk - elf_bss; if (clear_user((void __user *)elf_bss + load_bias, nbyte)) { /* * This bss-zeroing can fail if the ELF * file specifies odd protections. So * we don't check the return value */ } } Just curious. Reading through the code and trying to understand it... Rob -- GPLv3: as worthy a successor as The Phantom Meanace, as timely as Duke Nukem Forever, and as welcome as New Coke. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Andrew Morton on 21 Jul 2010 19:40 On Fri, 16 Jul 2010 15:12:39 -0500 Rob Landley <rob(a)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? > > nbyte = ELF_PAGEOFFSET(elf_bss); > if (nbyte) { > nbyte = ELF_MIN_ALIGN - nbyte; > if (nbyte > elf_brk - elf_bss) > nbyte = elf_brk - elf_bss; > if (clear_user((void __user *)elf_bss + > load_bias, nbyte)) { > /* > * This bss-zeroing can fail if the ELF > * file specifies odd protections. So > * we don't check the return value > */ > } > } > > Just curious. Reading through the code and trying to understand it... > 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(a)vger.kernel.org/msg60120.html http://www.mail-archive.com/bk-commits-head(a)vger.kernel.org/msg01390.html I don't kow how one would craft such an elf file. I don't _think_ it could leak unintialised memory, as we probably haven't faulted the page in yet. Perhaps a partial page could be exposed though. Roland, Jakub: help! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Roland McGrath on 21 Jul 2010 21:40
> On Fri, 16 Jul 2010 15:12:39 -0500 > Rob Landley <rob(a)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(a)vger.kernel.org/msg60120.html > http://www.mail-archive.com/bk-commits-head(a)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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |