On Wed, Jun 7, 2017 at 2:29 AM, Michael Ellerman <m...@ellerman.id.au> wrote: > Daniel Micay <danielmi...@gmail.com> writes: > >> Rather than doing this, the base should just be split for an ELF >> interpreter like PaX. > > I don't quite parse that, I think you mean PaX uses a different base for > an ELF interpreter vs a regular ET_DYN? > > That would be cool. How do you know that it's an ELF interpreter you're > loading? Is it just something that's PIE but doesn't request an > interpreter?
I talk a bit about the situation here: http://www.openwall.com/lists/kernel-hardening/2017/06/03/6 > Is the PaX code somewhere I can look at? It's near here: https://github.com/linux-scraping/linux-grsecurity/blob/grsec-test/fs/binfmt_elf.c#L1362 (Note the "&& elf_interpreter" part.) It's replacing the arch_rnd_mmap() result with its own under some situations, etc. To do something like this in upstream, we need to be sure we've sanely dealt with the brk region, which follows the first loaded ELF, and if it's the interpreter, that means brk ends up in mmap area, up near the executable area (near what would become the misnomer of ELF_ET_DYN_BASE -- should be ELF_PIE_BASE). -Kees -- Kees Cook Pixel Security