lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 22 Dec 2014 12:00:17 -0800
From:	Andy Lutomirski <>
To:	Jiri Kosina <>
Cc:	Hector Marco Gisbert <>,
	Cyrill Gorcunov <>,
	Pavel Emelyanov <>,
	Catalin Marinas <>,
	Heiko Carstens <>,
	Oleg Nesterov <>,
	Ingo Molnar <>,
	Anton Blanchard <>,
	Russell King - ARM Linux <>,
	"H. Peter Anvin" <>,
	David Daney <>,
	Andrew Morton <>,
	Arun Chandran <>,
	"" <>,
	Martin Schwidefsky <>,
	Ismael Ripoll <>,
	Christian Borntraeger <>,
	Thomas Gleixner <>,
	Hanno Böck <>,
	Will Deacon <>,
	Benjamin Herrenschmidt <>,
	Kees Cook <>,
	Reno Robert <>
Subject: Re: [PATCH] ASLRv3: randomize_va_space=3 preventing offset2lib attack

On Mon, Dec 22, 2014 at 11:49 AM, Jiri Kosina <> wrote:
> On Mon, 22 Dec 2014, Andy Lutomirski wrote:
>> a. With PIE executables, the offset from the executable to the
>> libraries is constant.  This is unfortunate when your threat model
>> allows you to learn the executable base address and all your gadgets
>> are in shared libraries.
> When I was originally pushing PIE executable randomization, I have been
> thinking about ways to solve this.
> In theory, we could start playing games with load_addr in
> load_elf_interp() and randomizing it completely independently from mmap()
> base randomization, but the question is whether it's really worth the
> hassle and binfmt_elf code complication. I am not convinced.

It could be worth having a mode that goes all out: randomize every
single allocation independently in, say, a 45 or 46-byte range.  That
would be about as strong ASLR as we could possibly have, it would
result in guard intervals around mmap data allocations (which has real
value), and it would still leave plenty of space for big address space
hogs like the Chromium sandbox.

The main downside would be lots of memory used for page tables.


> --
> Jiri Kosina
> SUSE Labs

Andy Lutomirski
AMA Capital Management, LLC
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists