Support for place independent executables
Hello. If you launch a PIE, the loader will map it in memory to a fixed
position (ET_DYN_LOAD_ADDR). This patch changes this behaviour and makes
the loader respect vm.randomize_map sysctl.
#3 Updated by shamaz over 3 years ago
I send a new patch with a bit more explanation in comments.
> can you explain why ET_DYN_LOAD_ADDR existed before
I don't know. It's just a hardcoded virtual address to be used instead of p_vaddr field of the first PT_LOAD program header, if the latter is 0. I think, it could be, say, 0x400000 as well as 0x1021000. The old code was brought there from FreeBSD which does not have ASLR, so hardcoded non-random value can be OK for it.
#4 Updated by marino over 3 years ago
okay, i didn't see the last hunk before. I couldn't figure out what was special about the value of "1".
The comments are going way past 80 columns though, so they need to be wrapped earlier.
I'll ask dillon if the last hunk is good. The rest of the patch looks okay to me.
#7 Updated by shamaz over 3 years ago
What is so special about ET_DYN_LOAD_ADDR? Is it really important to keep backward compatibility when vm.randomize_mmap=0? PIE code doesn't care where it is loaded in memory, no matter if it's randomized or not. Treat it like a shared library. Also it will not cause any trouble to userland programs, because world and ports are compiled as normal executables, not as PIEs. Currently, vm.randomize_mmap is only checked in vm_map_hint(), do you really want to check it somewhere else, making the code more complex and harder to understand? If you want, I can try to build some apps from DPorts with -pie flag and check if they are working (already tried flac decoder), just name it. If you want to keep ET_DYN_LOAD_ADDR, I'll just give up ) It is simpy a macro from FreeBSD which does not support ASLR at all.
#8 Updated by dillon over 3 years ago
I'd rather make changes like this slowly. Its enough for now to change it to support the randomization, but I don't want to change the defaults at the same time. The dynamic load address is basically in low (virtual) memory, whereas the hint I think is going to put it somewhere above the 32GB mark in VM. I'd rather not make that change (and, in fact, I don't really like the idea of putting the executable that high anyway)
#10 Updated by shamaz over 3 years ago
If you wish to save the old behaviour, you can look at this new patch I am sending. It adds a new sysctl kern.elf64.pie_base_mmap (you may want to change both name and description, I cannot think out any better). If it is set to 1, vm_map_hint() is used, ET_DYN_LOAD_ADDR otherwise.