[Bug ld/28824] relro security issues

[rfhn.fhbrrjnzeneqpf at noclue dot notk.org]

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

Dominique Martinet <rfhn.fhbrrjnzeneqpf at noclue dot notk.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rfhn.fhbrrjnzeneqpf@noclue.
                   |                            |notk.org

--- Comment #10 from Dominique Martinet <rfhn.fhbrrjnzeneqpf at noclue dot 
notk.org> ---
Hello,

I understand making sure the pages are separated is important for security, but
would it make sense to disable demand paging if the whole code is <
maxpagesize, and keep the previous binary layout to have the linker map it
correctly at runtime? (I assume the root of the problem is we cannot mmap at
non-multiples of page sizes, so this cannot be lazy paged...)
This could also be advantageous for memory usage on systems with smaller page
sizes, e.g. our system has 4K page size and does not need this much padding if
loaded at runtime, as runtime knows the page size actually in use.
(I guess it is wasteful if the memory is never used though...)

In particular, I'm concerned that this change caused binaries in alpine linux
to grow quite noticeably from 3.16 (binutils 2.38) to 3.17 (binutils 2.39), for
example the iptables package which has ~112 small .so (previously 8-12KB) now
all are ~68KB big, and the package jumped up from 1.5 to 7.5MB. This is quite
annoying for small embedded systems, our rootfs jumped up from ~160 to ~200MB
and we do not have much more space to spare.

If it could be possible to preserve small binary sizes that'd be really
appreciated, my idea might have been stupid so happy to hear other thoughts and
possibilities.

Related alpine issue:
https://gitlab.alpinelinux.org/alpine/aports/-/issues/14126



(please say if I should open a new bug for this instead, I just wanted to leave
a trace for people invovled in the original patch/problem first)

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