linux-kernel - Re: [PATCH] [RESEND] PIE executable randomization

lists.openwall.net		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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 14 Aug 2007 22:41:06 +0200 (CEST)
From:	Jiri Kosina <jkosina@...e.cz>
To:	Jakub Jelinek <jakub@...hat.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Roland McGrath <roland@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Ulrich Kunitz <kune@...ne-taler.de>,
	Bret Towe <magnade@...il.com>, linux-kernel@...r.kernel.org,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: [PATCH] [RESEND] PIE executable randomization

(added Arjan to CC, as he has been working on the kernel part of the 
randomization previously)

On Tue, 14 Aug 2007, Jakub Jelinek wrote:

> If I'm reading the above hunk correctly, this means we will randomize 
> all PIEs and even all dynamic linkers invoked as executables on i?86 and 
> x86_64, and on the rest of arches we won't randomize at all, instead 
> load ET_DYN objects at ELF_ET_DYN_BASE address. But I don't see anything 
> i?86/x86_64 specific on this.

Hi Jakub,

actually, it is currently arch-specific, and that's because of different 
memory layouts on different archs.

It turned out recently that PIE-compiled binaries on x86_64, that perform 
larger amount of brk-allocations (for example bash) will not work (but 
they will work on ?86). This is because currently on ?86 the memory layout 
is as follows:

[TEXT][HEAP]...[MMAP area]..[STACK]..[VDSO]

for PIE-complied binaries, the situation is as follows (with the patch):

[MMAP area]...[TEXT][HEAP]..[STACK]..[VDSO]

which is perfectly fine (except for the non-randomized brk). However, on 
x86_64, the memory layout is different:

[TEXT][HEAP][MMAP area]..[STACK]..[VDSO]

which directly shows why brk() doesn't work well here -- it very soon hits 
another mmaped VMA.

I am currently thinking about the best way to address this issue -- I am 
thinking about randomizing brk properly (which we want to do anyway), so 
that it is placed in the area that doesn't overlap with mmap range.

> What would make much more sense to me would be conditionalizing on
> whether we are loading a dynamic linker (in which case loading it
> at ELF_ET_DYN_BASE is desirable or not (PIEs, ...; and for PIEs we
> want to randomize on all architectures).

Yes, I agree -- when we sort out the memory layout problems.

Thanks,

-- 
Jiri Kosina
SUSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/