Bug 1051239

You haven't said which architecture this is on, but in any case, I wonder why do you expect that -fPIC wouldn't have significant performance impact.  It of course has significant performance impact, even on x86_64.

I have performed the tests on x86_64.

Well, over 50% performance drop is a HUGE number. In fact, the performance drop is as large as 80% when online statistical testing of the produced data is enabled.

Plus there is no measurable performance drop when using  gcc 4.7.2. See bellow results on F18 with gcc (GCC) 4.7.2 20121109 (Red Hat 4.7.2-8). This is why I believe it's a bug in gcc 4.8.2


$haveged_default/sbin/haveged -otc -n0 | dd iflag=fullblock of=/dev/null bs=4k count=262144
Writing unlimited bytes to stdout
262144+0 records in
262144+0 records out
1073741824 bytes (1.1 GB) copied, 3.09276 s, 347 MB/s


$haveged_fPIC_z_now/sbin/haveged -otc -n0 | dd iflag=fullblock of=/dev/null bs=4k count=262144
Writing unlimited bytes to stdout
262144+0 records in
262144+0 records out
1073741824 bytes (1.1 GB) copied, 3.10366 s, 346 MB/s

Well, if it is a binary rather than shared library, then using -fPIC makes no sense, plus if you aren't linking it as a -pie even -fPIE doesn't make sense.
Hardening effect (very little in fact) is only achieved if you build the binary as a -pie, and in that case you should compile it's source files with -fPIE.  You might get better performance with -fPIE over -fPIC, in that case the compiler can assume locally defined public symbols bind locally and thus can use IP relative addressing instead of extra indirection.  Similarly, you can improve code by using visibility attribude, guaranteeing to the compiler what symbols will be defined in the binary and thus can be addressed directly (which is ~ as expensive as accessing vars for -fno-pic).

Hi Jakub,

thanks for sharing this information. Clearly

https://fedoraproject.org/wiki/Packaging:Guidelines#PIE

is misleading as it states:
====================================================================
%global _hardened_build 1

This adds -fPIC (if -fPIE is not already present) to the compiler flags, and adds -z now to the linker flags. 
====================================================================

The package consists of shared library and front-end program compiled against this shared library.

I will try
CFLAGS=-fPIE LDFLAGS=-pie ./configure 

and post my results here. 

Could you please comment on hardening effect with CFLAGS=-fPIE LDFLAGS=-pie flags? Is it worth the effort? In comment 4 you say that hardening effect is very little, is that right?

Jirka

Using 

CFLAGS=-fPIE LDFLAGS=-pie ./configure 

I see the same performance drop with gcc 4.7.2 and gcc 4.8.2


CFLAGS=-fPIE LDFLAGS=-pie ./configure compared to regular build brings performance drop from 346MB/s to 200MB/s :

./haveged_PIE/sbin/haveged -otc -n0 | dd iflag=fullblock of=/dev/null bs=4k count=262144
Writing unlimited bytes to stdout
262144+0 records in
262144+0 records out
1073741824 bytes (1.1 GB) copied, 5.37325 s, 200 MB/s

Please comment on the results. If this is expected I will close the bug. How much does this bring in terms of hardening?

Jirka

Jiri,

The performance drop would be highly dependent on the code's behaviour.  While a 50% hit is bad and higher than is typically seen with these options, it's not out of the realm of possibility.  I would suggest using some profiling tools to explore why your application is impacted so heavily and take appropriate action (possibly with some input from Jakub and the larger tools team about how to mitigate the impact).


The hardening effect of PIE is randomize the address space which makes exploiting return-to-libc and ROP attacks harder because its harder to predict where "interesting" code sequences are within the address space.  Typically these are secondary methods of attack -- ie, the bad guys start with a buffer overflow, and then have to resort to ROPs and similar mechanisms to enable the exploit.