Kees Cook <keesc...@chromium.org> writes: > On Fri, Jun 23, 2017 at 12:01 AM, Michael Ellerman <m...@ellerman.id.au> > wrote: >> Kees Cook <keesc...@chromium.org> writes: >> >>> Now that explicitly executed loaders are loaded in the mmap region, >>> position PIE binaries lower in the address space to avoid possible >>> collisions with mmap or stack regions. For 64-bit, align to 4GB to >>> allow runtimes to use the entire 32-bit address space for 32-bit >>> pointers. >> >> The change log and subject are a bit out of whack with the actual patch >> because previously we used 512MB. >> >> How about? >> >> powerpc: Move ELF_ET_DYN_BASE to 4GB / 4MB >> >> Now that explicitly executed loaders are loaded in the mmap region, >> we have more freedom to decide where we position PIE binaries in the >> address space to avoid possible collisions with mmap or stack regions. >> >> For 64-bit, align to 4GB to allow runtimes to use the entire 32-bit >> address space for 32-bit pointers. On 32-bit use 4MB. > > Good idea, thanks. I'll resend the series with the commit logs updated. > >> Is there any particular reasoning behind the 4MB value on 32-bit? > > So, I've dug around a bit on this, and I *think* the rationale is to > avoid mapping a possible 4MB page table entry when it won't be using > at least a portion near the lower end (NULL address area covered > blocked by mmap_min_addr). It seems to be mainly tradition, though.
OK, that is obscure, especially for CPUs that don't have a 4MB page size. But consistency across arches is probably best regardless. cheers