I'm looking into it. So far I have contacted the author and there might be issues with quality of random numbers when using PIC. See below.

I will run test using TestU01 and PractRand statistical tests to see if PIC is causing any degradation in the quality of results.

Could you please do the testing on your side as well? The more testing coverage we have we can make better decision.

FYI - the feedback from the author is here:

========================================================================
I have no direct experience with PIC generated by gcc, but I do remember haveged PIC build problems reported (clobbered %ebx) in version 1.1 days that were ultimately solved by introducing <cpuid.h>. I cannot recall any other inline assembly issues after migration to compiler intrinsics was completed in v1.2, but I don't have a very good picture of usage outside of what I hear from distro maintainers.

Of course a lot has changed since v1.2, especially the layout of the collection code. The big changes were the replacement of a computed goto with an inline equivalent (see the LOOP(n,m) macro) and the relocation of the collection loop variables to allow multiple instances for multi-threading. I don't remember the last time I looked at the assembly, but my guess is any relocation created by LOOP(n,m) or "oneinteration.h" will redirect through the global offset table in a PIC compile. This will drastically alter the layout of the collection loop and may cause problems, but there is no way to know without giving it a try. I am interested enough to have a look at the generated assembly when I get some time. As I recall, x86 and amd64 use very different PIC code strategies. I have no idea or opportunity to test on the other architectures at the moment.

If haveged builds with PIC, there is a chance it may just work. The collection loop does not have to be perfect, just good enough. If the build produces something that runs,  the online test feature will fail initialization if gcc gets too creative generating the collection loop.  That's the theory anyway.

In the words of Yogi Berra: In theory there is no difference between theory and practice. In practice there is.
========================================================================

Hi,

I have bumped into what I believe to be a gcc bug on F19, F20 and RHEL7. F18 is not affected.

See BZ1051239

When I enable hardening
CFLAGS=-fPIC LDFLAGS="-z now" ./configure --prefix=/${HOME}/haveged/haveged_fPIC_z_now_binary

there is a 50% performance drop:

 ./haveged_default_binary/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.30622 s, 325 MB/s

$ ./haveged_fPIC_z_now_binary/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.34215 s, 201 MB/s

The drop is even worse when online testing is enabled.

Marking this as dependant on BZ1051239. I'm not going to enable these options until the above gcc issue gets addressed.

I know there must be such reduction...

Will follow that bug now.

Thanks for your patience on this bug!

*** Bug 1051337 has been marked as a duplicate of this bug. ***

Hi Christopher,

let's which course does it take.

At the moment it does not look very good: the author of the package is worried about the side effects of this change plus enabling CFLAGS=-fPIE LDFLAGS=-pie is causing performance degradation by more than 50%. Plus Jakub Jelinek, one the gcc developers has stated that hardening effect is in fact very little. 

Jirka

Yes, I understand. I've followed all threads.

Then I think we should keep it like before in normal state. As haveged is used in many areas, I don't want to make it slower than before just because of the compiler. 

Upstream may need to cleanup the code, but this is not the thing I'm concerned about currently.

Thanks.

Hi Christopher,

in fact this BZ had a positive side effect - I have started an extensive tests and it has revealed one bug in the online statistical testing code (tests test7a and 7b could erroneously mark the block of random data as invalid) and couple of minor bugs. I'm in contact with the author and he is working on it, updated release should be ready in couple of days. In case you see some problem in the code please let me know and I will communicate it to the author.

I will keep this Bug open and watch the progress on the gcc issue. Once it will get fixed we can reconsider enabling PIE for haveged.

Thank you
Jirka

> in fact this BZ had a positive side effect

glad to hear!

> performance drop from 346MB/s to 200MB/s

uhm we are talking about random numbers

This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22

Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.