On Sat, Feb 17, 2024 at 04:25:33PM -0800, H. Peter Anvin wrote: > On February 16, 2024 10:25:42 PM PST, Kees Cook <[email protected]> wrote: > >Hi, > > > >It was recently pointed out[1] that x86_64 brk entropy was not great, > >and that on all architectures the brk can (when the random offset is 0) > >be immediately adjacent to .bss, leaving no gap that could stop linear > >overflows from the .bss. Address both issues. > > > >-Kees > > > >Link: > >https://lore.kernel.org/linux-hardening/CA+2EKTVLvc8hDZc+2Yhwmus=dzoug5e4gv7aycbu0mpjtzz...@mail.gmail.com > > [1] > > > >Kees Cook (2): > > x86: Increase brk randomness entropy on x86_64 > > binfmt_elf: Leave a gap between .bss and brk > > > > arch/x86/kernel/process.c | 5 ++++- > > fs/binfmt_elf.c | 3 +++ > > 2 files changed, 7 insertions(+), 1 deletion(-) > > > > Why do we even have the brk, or perhaps more importantly, why do we use it? > Is there any reason whatsoever why glibc uses brk instead of mmap to her heap > memory? > > I thought the base of the brk wasn't even known to userspace other than in > the form of the image end...
AFAIK, it's part of ELF ABI, and the loader uses it only for very early allocations. e.g. it's what shows up as "[heap]" in /proc/$pid/maps. It's also available to any program that wants it still (see "man brk"). I don't think glibc has plans to redirect it. -- Kees Cook
