(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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
