Security-improving technologies which could be deployed now [LWN.net]

Security-improving technologies which could be deployed now

Posted Oct 16, 2004 0:22 UTC (Sat) by garloff (subscriber, #319)
In reply to: Security-improving technologies which could be deployed now by ballombe
Parent article: Security-improving technologies which could be deployed now

> As for the 1% overhead for PIE executable on x86, for programs making
> heavy use of global symbols in critical path, the overhead is closer
> to 5% and I have examples (using hand-made assembly) where it reach
> 20%.

Indeed, on x86, where you already have a shortage of general purpose
registers, PIC will waste one more integer register.
Unfortunately, this happens on compute intensive tasks where you really
care. Think bzip2, gcc, ...
5% is the number seen by me as well.

On x86-64, you have twice as many GPRs and you normally don't even need
to offer one for PIC, due to the nice RIP relative addressing mode.
Thus the low overhead. The gcc/toolchain developers have done a nice
job of making sure that PIC code runs nicely on x86-64!

(Log in to post comments)

Security-improving technologies which could be deployed now

Posted Oct 21, 2004 19:51 UTC (Thu) by bluefoxicy (guest, #25366) [Link]

"Unfortunately, this happens on compute intensive tasks where you really
care. Think bzip2, gcc, ..."

icebox ~ # file /lib/libz.so.1.2.1
/lib/libz.so.1.2.1: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped
icebox ~ # file /usr/lib/libbz2.so.1.0.2
/usr/lib/libbz2.so.1.0.2: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped

This isn't PIE; these are shared libraries, which on all systems are PIC. Notice that much if not most or almost all heavy lifting--compression, multimedia encoding/decoding, networking operations, X graphics card drivers, X extensions such as composite and glx and even MESA SW GL, window drawing toolkits such as GTK or QT--are all libraries. Libraries are all shared objects, which are PIC.

PIE (Position Independent Executables) are just PIC executables, i.e. things in */bin.

icebox ~ # file /bin/bzip2
/bin/bzip2: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped

So unfortunately the overhead happens in the most critical places anyway.

As for eating 1%-20%, microbenchmarks are cute but useless. They're theoretical maximums; but as illustrated here, the heavy lifting is done where you can't avoid them.

I got closer to 5% when testing with -fomit-frame-pointer; however, the difference between '-fomit-framepointer -fPIC' and neither is still 1%. It appears that the gains of -fomit-frame-pointer are lost completely with -fPIC, *and* the normal overhead of -fPIC is added, creating an illusionary 5-6% overhead.