[Bug ld/23567] much larger static binaries compared to a few months ago

[felix-glibc at fefe dot de]

https://sourceware.org/bugzilla/show_bug.cgi?id=23567

--- Comment #4 from Felix von Leitner <felix-glibc at fefe dot de> ---
Hey Nick, thanks for the quick help!

With -z noseparate-code I'm down to 9512 bytes. That is much better but still
more than gold produces. And looking at the binary in a hex editor still shows
a ton of padding bytes after .text and .data.

I could theoretically bring my own linker scripts, but I would have to maintain
them for all the supported architectures. I'm not sure I'm up to that task.

The data segment has been marked non-executable the whole time. I suspect you
mean rodata. The difference would be that those are no longer mapped as
executable, but they are not mapped as writable either. So what attack exactly
are we preventing here?

I also wonder if the segments actually have to be on different pages for this
to work. Let's say you have both writable data and read-only data and code on
the same page in the file. The kernel would mmap the page once
read-write-private-copyonwrite for .data, once read-only-private-shared for
rodata (but at some other place in virtual memory), and a third time as
readonly-executable for .text, correct? So even if you could write to the page
via the copy-on-write mapping, that would not change what the private+shared
mappings are seeing.

I'm not sure what security we are actually buying here. Is there documentation
about this?

-- 
You are receiving this mail because:
You are on the CC list for the bug.