Binutils and bloat

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Binutils and bloat

Michael Deutschmann-2
This may be stretching into off-topic, but I think it fits here since
most people here care about bloat and are using a mostly-GNU toolchain.

Binutils-2.28 came out two months ago, but I've put off moving to it
because I noticed that executables are bloated compared to 2.27. Usually
it's minor, but in one case (the "as" program in binutils itself), the
executable more than doubles in size.

I've reported the bug, and the underlying cause is understood now, but I
can't get them to fix it.  (It's closed binutils bug #21448).

Basically, between 2.27 and 2.28 someone noticed that if you violate the
const-ness of a symbol imported from an ELF shared library, no segfault
occurs.  This is because (at least in recent binutils) such symbols are
"copy reloc"ed to a spot in the executable's BSS region, avoiding the need
for as many relocations at run time.  Since the entire BSS remains
writable, this means that const doesn't do much of anything from within a
shared library.

They decided this was a "security flaw", and rewrote 2.28 to place such
copy symbols in a separate section covered by relro.  This section, like
BSS, is all zeros.  But unlike BSS, all those zeros take up actual space
in the file.  Due to the way paging works, the bloat is difficult to fix
without giving up this alleged "security" or bloating RAM use.

On my system GNU "as" is ~240k of real code that references a ~430k
constant table from the "libopcodes" library, so bloat is severe.

I personally don't see how the lack of segfaults constitues any security
problem worth this level of bloat.  You could as much call it a flaw
that .rodata isn't usually made no-execute at a hardware level.

Hopefully, people here can either come up with some subtle reason the
binutils people are in fact right, or knock some sense into them for

(Note that I've already patched away the odious behavior for myself.)

---- Michael Deutschmann <[hidden email]>
uClibc mailing list
[hidden email]