| 1 |
> pageexec@××××××××.hu wrote: |
| 2 |
> the above is the result of using -fstack-protector-all (which enables |
| 3 |
> ssp in gcc and will create the __guard/__stack_smash_handler references) |
| 4 |
> and -nostdlib that will prevent linking to libc (where these symbols |
| 5 |
> normally resolv). i wonder how that -fstack-protector-all ended up |
| 6 |
> there since you're not using a hardened gcc. |
| 7 |
|
| 8 |
Bingo!!! I'm impressed. From a prior install of Gentoo, I still had "-fstack-protector-all" in my CFLAGS. |
| 9 |
|
| 10 |
So, what is the right way to add SSP to everything (including the kernel) for Gentoo with a 2.6.7+ kernel, without adding Pax ASLR? |
| 11 |
|
| 12 |
I do plan on enabling ASLR later, but my system has many complexities -e.g. I have a custom selection of kernel patches, including most of the non-selinux patches from hardened-dev-sources. I prefer to make changes in a series of steps, rather than many changes at the same time. The last time I tried a full Gentoo system with ASLR enabled (several months ago), gdb didn't work on PHP .. a big problem for me. |
| 13 |
|
| 14 |
> prelink doesn't significantly reduce physical memory usage, rather |
| 15 |
> it speeds up runtime linking (by mapping shared libraries at the same |
| 16 |
> virtual addresses hence saving on runtime relocation). there will be |
| 17 |
> some memory savings for shared libraries whose .got is large enough |
| 18 |
> to spread over several physical pages, but that's hardly measurable |
| 19 |
> to the .data and other sections (not to mention the stack/heap) that |
| 20 |
> constitute the major part of a task's physical memory usage (as in, |
| 21 |
> physical memory that has to be instantiated per task and is not shared |
| 22 |
> between them). |
| 23 |
> |
| 24 |
> PaX doesn't affect physical memory usage much, only the stack and the |
| 25 |
> brk() managed heap will take up to one extra page each. the extra virtual |
| 26 |
> memory usage is almost the same, one page for the stack and 16 pages |
| 27 |
> for the brk() heap. what really changes under PaX (and what is at odds |
| 28 |
> with prelink) is the random start addresses of various address regions |
| 29 |
> (heap/stack/libs/etc) and the gaps between them (i.e., the maximum size |
| 30 |
> of a mapping that'd fit in there). |
| 31 |
|
| 32 |
So the code segments for the shared libraries really are shared when using 2.6.x with Pax ASLR? That seems right .. but I'm not familiar enough with the linker and kernel to know for sure. I looked in /proc, but couldn't find an easy way to determine exactly what was actually shared and what wasn't being shared between processes. |
| 33 |
|
| 34 |
When I create my next system and add Pax, then I can measure approximately the total difference in memory usage resulting from adding Pax. If prelink brings so little memory savings over Pax ASLR, then why would anyone want to use prelink instead of Pax ASLR on a server? Prelink also can only randomize the start address of shared libraries, not the code segment for the binary in question - unlink ASLR, right? Maybe the link speed for a desktop system matters, but otherwise .. |
| 35 |
|
| 36 |
You guys rock! How do you get so smart? I read most of the docs I find .. but you guys are way beyond the docs =) |
Archives