On Mon, Dec 9, 2013 at 1:13 PM, Jiri Kosina <[email protected]> wrote: > On Mon, 9 Dec 2013, H.J. Lu wrote: > >> >> Normally, a PIE executable has zero virtual address on the first PT_LOAD >> >> segment and kernel will load such executable at random address when >> >> randomization is enabled. If randomization is disabled, kernel will load >> >> it at a fixed address. But if a PIE executable has non-zero virtual >> >> address on the first PT_LOAD segment, kernel will load such executable >> >> at the non-zero virtual address when randomization is enabled. But when >> >> randomization is disabled, kernel ignores the non-zero virtual address >> >> at the non-zero virtual address when randomization is enabled. >> > >> > Hmm ... isn't actually this the thing that needs to be fixed instead? >> > >> > IOW, when randomization is enabled, is there a reason not to load on >> > randomized address? (even if the first PT_LOAD segment has non-zero >> > vaddr?) >> >> No, please don't do that. Normally, PIE has zero load address and kernel >> can load it anywhere. There are multiple reasons why PIE has non-zero >> load address. Saying you need to load a program above 4GB under x86-64, >> you can't do that with normal dynamic executable. PIE with non-zero load >> address is the only way to do that on x86-64. > > Hmm, so if it's because of 4G PT_LOAD limit, how about at least adding
Yes. > randomized offset to the supplied vaddr? Yes, people who build PIE with non-zero vaddr can use randomized vaddr. But kernel must follow the non-zero vaddr. > PT_LOAD being non-zero causing randomization to be turned off seems like > quite unexpected behavior to me, with a great potential to cause a lot of > confusion. > There should be no difference between dynamic executable and PIE with non-zero vaddr when choosing where to load them. -- H.J. -- 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/
