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. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
