Submit #2854
closed
Support for place independent executables
0%
Description
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.
Files
Updated by shamaz about 9 years ago
- Tracker changed from Bug to Submit
- Category set to Kernel
Updated by marino about 9 years ago
- Honour the base load address from the dso if it is
- non-zero for some reason."
as well?
can you explain why ET_DYN_LOAD_ADDR existed before and why "1" is the correct value for
et_dyn_add ?
Updated by shamaz about 9 years ago
- File pie2.patch pie2.patch added
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.
Updated by marino about 9 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.
Updated by shamaz about 9 years ago
- File pie3.patch pie3.patch added
The comments are going way past 80 columns though, so they need to be wrapped earlier.
Fixed in the new patch. I hope everything is OK now.
Updated by dillon about 9 years ago
The only issue I see is that we want the previous behavior of using ET_DYN_LOAD_ADDR to remain if randomization is turned off and it doesn't appear to be.
-Matt
Updated by shamaz about 9 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.
Updated by dillon about 9 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)
-Matt
Updated by shamaz almost 9 years ago
- File pie_sysctl.patch pie_sysctl.patch added
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.
Updated by shamaz almost 9 years ago
It also replaces 8 or more spaces with tab(s) in two or three places.
Updated by marino almost 9 years ago
sorry, i've been busy with other stuff, I'll try to flag dillon's attention to this the next time I see him. I don't know if he was asking for new sysctls though.