| 1 |
On 27 Feb 2011 at 9:53, Anthony G. Basile wrote: |
| 2 |
|
| 3 |
> >> Most of the asm code is in libs and on amd64 it need to be PIC friendly |
| 4 |
> >> from |
| 5 |
> >> the start. We don't need to disable asm code. We do that most times with |
| 6 |
> >> the |
| 7 |
> >> pic use flag on hardened profile. |
| 8 |
> >> |
| 9 |
> >> /Magnus |
| 10 |
|
| 11 |
that's actually not the intended use of the PIC USE flag, we wanted it originally |
| 12 |
to enable configuring/compiling position independent code for packages where one |
| 13 |
wanted to make a tradeoff between speed/security (i think php was one such app, |
| 14 |
even without any hand written asm code). |
| 15 |
|
| 16 |
so with USE=pic you were supposed to get a textrel free, but potentially slower |
| 17 |
binary (partly because of the PIC overhead on i386 and partly because sometimes |
| 18 |
it meant using the C implementation of some algo instead of hand written asm). |
| 19 |
|
| 20 |
at the same time to recover some performance we had a project to fix all the |
| 21 |
position dependent asm code in all the multimedia and other libs (you can still |
| 22 |
find some lingering patches in bugzilla from me), but unfortunately some never |
| 23 |
made it upstream (some of them are even openly 'hostile' to PIC and went as far |
| 24 |
as removing what little PIC they had or had unreasonable constraints like supporting |
| 25 |
long-dead gcc versions). |
| 26 |
|
| 27 |
so even if right now getting PIC requires using C code instead of (badly written) |
| 28 |
asm, it doesn't have to be this way. if anyone wants to take this up again, talk |
| 29 |
to me and i can point you at the patches i have (ffmpeg, xvid, xine are the really |
| 30 |
big ones) and the gentoo docs written about the topic. |
| 31 |
|
| 32 |
> An example of where it does is an attempt to defeat address space |
| 33 |
> randomization by brute force. 32-bit address space is only 4G which is |
| 34 |
> not impossibly large for success by brute force while 64-bits is about |
| 35 |
> 10^19. A lot harder. |
| 36 |
|
| 37 |
that's only theory ;), in practice CPUs don't implement all 64 virtual bits, |
| 38 |
e.g., on amd64 you have 'only' 48 bits (normally split into two 47 bit halves |
| 39 |
for userland/kernel, except for UDEREF where userland gets only 42). |
Archives