gentoo-hardened February 2011 archive
Main Archive Page > Month Archives  > gentoo-hardened archives
gentoo-hardened: Re: [gentoo-hardened] Re: Remove the pic use fl

Re: [gentoo-hardened] Re: Remove the pic use flag in the hardened amd64 profile.

From: <pageexec_at_nospam>
Date: Sun Feb 27 2011 - 22:58:52 GMT

On 27 Feb 2011 at 9:53, Anthony G. Basile wrote:

> >> Most of the asm code is in libs and on amd64 it need to be PIC friendly
> >> from
> >> the start. We don't need to disable asm code. We do that most times with
> >> the
> >> pic use flag on hardened profile.
> >>
> >> /Magnus

that's actually not the intended use of the PIC USE flag, we wanted it originally
to enable configuring/compiling position independent code for packages where one
wanted to make a tradeoff between speed/security (i think php was one such app,
even without any hand written asm code).

so with USE=pic you were supposed to get a textrel free, but potentially slower
binary (partly because of the PIC overhead on i386 and partly because sometimes
it meant using the C implementation of some algo instead of hand written asm).

at the same time to recover some performance we had a project to fix all the
position dependent asm code in all the multimedia and other libs (you can still
find some lingering patches in bugzilla from me), but unfortunately some never
made it upstream (some of them are even openly 'hostile' to PIC and went as far
as removing what little PIC they had or had unreasonable constraints like supporting
long-dead gcc versions).

so even if right now getting PIC requires using C code instead of (badly written)
asm, it doesn't have to be this way. if anyone wants to take this up again, talk
to me and i can point you at the patches i have (ffmpeg, xvid, xine are the really
big ones) and the gentoo docs written about the topic.

> An example of where it does is an attempt to defeat address space
> randomization by brute force. 32-bit address space is only 4G which is
> not impossibly large for success by brute force while 64-bits is about
> 10^19. A lot harder.

that's only theory ;), in practice CPUs don't implement all 64 virtual bits,
e.g., on amd64 you have 'only' 48 bits (normally split into two 47 bit halves
for userland/kernel, except for UDEREF where userland gets only 42).