| 1 |
Ryan Hill <dirtyepic@g.o> wrote: |
| 2 |
> |
| 3 |
>> > * -Wl,-z,relro |
| 4 |
>> > Enabled by default since binutils 2.18 |
| 5 |
>> |
| 6 |
>> This gives its real impact on secutiry only when combined with |
| 7 |
>> |
| 8 |
>> * -Wl,-z,now |
| 9 |
>> |
| 10 |
>> The latter is not enabled by default AFAIK. |
| 11 |
> |
| 12 |
> That's a bit misleading. Immediate binding does allow the GOT to be made |
| 13 |
> readonly but relro does a lot more than that. |
| 14 |
|
| 15 |
It is somewhat pointless if not everything is readonly: |
| 16 |
In analogy, "relro" without "now" is a bit like making all your files |
| 17 |
readonly but leaving write-permissions on the directories. |
| 18 |
It only helps against too poorly designed exploits of corresponding |
| 19 |
bugs. |
| 20 |
|
| 21 |
> In any case this is a firm no. |
| 22 |
> The increase in loading times for apps that link lots of libraries is |
| 23 |
> significant (if it wasn't, we wouldn't need lazy loading :p). |
| 24 |
|
| 25 |
You get the same delay for lazy linking, only not necessarily |
| 26 |
everything immediately when the application starts up. |
| 27 |
And even then it is only faster (at startup) if only very few symbols |
| 28 |
are needed near the beginning. |
| 29 |
|
| 30 |
Quite the opposite, total time of loading huge projects like |
| 31 |
kde or libreoffice can even be faster with "now", since you do |
| 32 |
not need administration overhead for keeping track of resolving. |
| 33 |
I did not realize a measurable difference for kde and libreoffice |
| 34 |
even on my slow machines - random things like location on harddisk |
| 35 |
apparently had a much bigger impact on startup. |
| 36 |
Please really try before you fix your opinion. |
| 37 |
|
| 38 |
>> * -Wl,-z,noexecstack |
| 39 |
> |
| 40 |
> Well, portage will already tell you if your package installed any |
| 41 |
> binaries with executable stacks |
| 42 |
|
| 43 |
For some it did warn - otherwise I would not have found the bug. |
| 44 |
But for some it did not. However, I cannot recall which packages |
| 45 |
these were, and I did not examine why. |
| 46 |
Anyway, since this probably only concerns certain gcc versions |
| 47 |
with -flto, I guess that we need not discuss much about this flag. |
| 48 |
|
| 49 |
>> However, isn't it time to use "gnu" now for all users? [...] |
| 50 |
> |
| 51 |
> Sure, but the sysv hash is teeny and backward compatibility is |
| 52 |
> always nice if it's next to free. |
| 53 |
|
| 54 |
But it is not completely free, and the majority of users |
| 55 |
will never have any need for it - in factõ I do not know |
| 56 |
any use-case, but of course I do not know all ancient software |
| 57 |
sitting around somewhere. |
| 58 |
Those few who need it can add the option without difficulties. |
Archives