Expanding the list of "Hardened Packages"

[Jakub Jelinek]

On Thu, Apr 04, 2013 at 10:27:31AM +0200, Florian Weimer wrote:
> On 04/04/2013 09:47 AM, Jakub Jelinek wrote:
> >On Thu, Apr 04, 2013 at 09:39:18AM +0200, Paolo Bonzini wrote:
> >>>I'm willing to agree that PIE on x86 is going to be very slow due to
> >>>register pressure.
> >>
> >>Yes, but not on x86-64 which has %rip-relative addressing.  It is
> >>probably a wash there.
> 
> On x86_64, GCC uses %rip-relative addressing even in non-PIC mode.

Only rarely, when it is less expensive or a wash.  Whenever you need more
complex addressing modes, we don't emit %rip addressing for non-pic and have
to do for pic.  Say we emit:
movzwl  local_symbol(%rsi,%rsi), %edx
for non-pic, but have to emit:
leaq    local_symbol(%rip), %rax
movzwl  (%rax,%rsi,2), %edx
for pic/pie code (and only when the symbol in static/hidden, otherwise there
would need to be an extra indirection).

> I think a similar optimization would be possible for access to
> global variables because ld could compute the final layout of all
> global variables in the binary itself, just as in the non-PIE case.

Nope.  The thing is, depending on if the variable is known to bind locally
(for PIC that is essentially static or hidden visibility, for PIE you can
add to that global vars defined in the current CU), you either emit code
that avoids the indirection (say %rip addressing, GOTOFF etc.), or emit code
that does the indirection, there is no linker relaxation that could turn
(albeit with worse generated code, increased register pressure etc.) code
that uses indirection (loads from GOT) into one that doesn't, we'd need
extra relocations and as that there are just too many forms of the
instructions on i?86/x86_64, it would be pretty hard.  So, PIE is
definitely not for free, not even on x86_64.

	Jakub