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).
