Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 21 Jun 2017 14:24:26 -0400
From: Rik van Riel <riel@...hat.com>
To: Kees Cook <keescook@...omium.org>, Andrew Morton
 <akpm@...ux-foundation.org>
Cc: Daniel Micay <danielmicay@...il.com>, Qualys Security Advisory
 <qsa@...lys.com>, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar
 <mingo@...hat.com>, "H. Peter Anvin" <hpa@...or.com>, x86@...nel.org, 
 Alexander Viro <viro@...iv.linux.org.uk>, Dmitry Safonov
 <dsafonov@...tuozzo.com>, Andy Lutomirski <luto@...capital.net>, Grzegorz
 Andrejczuk <grzegorz.andrejczuk@...el.com>,  Masahiro Yamada
 <yamada.masahiro@...ionext.com>, linux-kernel@...r.kernel.org,
 linux-fsdevel@...r.kernel.org,  kernel-hardening@...ts.openwall.com
Subject: Re: [PATCH v2] binfmt_elf: Use ELF_ET_DYN_BASE only for PIE

On Wed, 2017-06-21 at 10:32 -0700, Kees Cook wrote:

> To allow for a lower ELF_ET_DYN_BASE, loaders (ET_DYN without INTERP)
> are loaded into the mmap region, leaving space available for either
> an
> ET_EXEC binary with a fixed location or PIE being loaded into mmap by
> the
> loader. Only PIE programs are loaded offset from ELF_ET_DYN_BASE,
> which
> means architectures can now safely lower their values without risk of
> loaders colliding with their subsequently loaded programs.
> 
> For 64-bit, ELF_ET_DYN_BASE is best set to 4GB to allow runtimes to
> use
> the entire 32-bit address space for 32-bit pointers.
> 
> Thanks to PaX Team, Daniel Micay, and Rik van Riel for inspiration
> and
> suggestions on how to implement this solution.
> 
> Fixes: d1fd836dcf00 ("mm: split ET_DYN ASLR from mmap ASLR")
> Cc: stable@...r.kernel.org
> Signed-off-by: Kees Cook <keescook@...omium.org>

Acked-by: Rik van Riel <riel@...hat.com>

Powered by blists - more mailing lists

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.