1 |
On Tue, 26 May 2020 10:45:39 -0400 |
2 |
Mike Gilbert <floppym@g.o> wrote: |
3 |
> > Note that having the 'pic' useflag should be considered something |
4 |
> > to be fixed: rewrite the asm in a PIC way. But these days nobody |
5 |
> > has the will to do it since this is mostly an issue on x86+pax, |
6 |
> > both being slowly decreasing. |
7 |
> |
8 |
> Given that PaX has been stripped out of official Gentoo kernels due to |
9 |
> the grsecurity licensing issue, I wonder if there is any other good |
10 |
> reason to keep the "pic" USE flag today. Surely this affects a very |
11 |
> small population of users. |
12 |
|
13 |
|
14 |
I couldn't find any recent reference, but PIC shared libs used to be a |
15 |
QA policy. There's mainly two reasons to it: First is W^X enforcement; |
16 |
non PIC shared libs are refused by the x86_64 linker so a non-issue |
17 |
there, on x86 you need pax to emulate it because the mmu doesn't support |
18 |
the X part; I don't know about other arches. |
19 |
Then there is the small memory waste done because those libs will be |
20 |
loaded COW and thus their "code" is not shared anymore between |
21 |
processes. And the small startup performance hit to |
22 |
perform the relocations. |
23 |
|
24 |
The latter part affects everyone, and the rule of thumb for having a |
25 |
pic useflag (instead of always pic) is that the gain for non-pic asm is |
26 |
better than the loss of non-pic shared libs. This is subjective but |
27 |
usually a no-brainer for multimedia packages. |
28 |
|
29 |
This is probably something to bring up to QA too. |