F22 System Wide Change: Harden all packages with position-independent code

drago01 drago01 at gmail.com
Fri Jan 9 07:54:12 UTC 2015


On Fri, Jan 9, 2015 at 12:44 AM, Reindl Harald <h.reindl at thelounge.net> wrote:
>
> Am 09.01.2015 um 00:35 schrieb drago01:
>>
>> On Fri, Jan 9, 2015 at 12:16 AM, Dennis Gilmore <dennis at ausil.us> wrote:
>>>
>>> On Thu, 08 Jan 2015 20:25:36 +0100
>>> Reindl Harald <h.reindl at thelounge.net> wrote:
>>>>
>>>>
>>>> Am 08.01.2015 um 19:45 schrieb Miloslav Trmač:
>>>>>>
>>>>>> = Proposed System Wide Change: Harden all packages with
>>>>>> position-independent code =
>>>>>>
>>>>>> Harden all packages with position-independent code to limit the
>>>>>> damage from certain security vulnerabilities.
>>>>>
>>>>>
>>>>> So this proposal is for _all_ architectures, including the
>>>>> register-starved 32-bit i?86 where the overhead is, IIRC, around
>>>>> 10%.  I am by now quite convinced that x86_64 should be using PIE
>>>>> by default.  As for 32-bit, I’m torn between “this is too much
>>>>> overhead” and “32-bit isn’t worth the worry, let’s instead make the
>>>>> defaults consistent.”
>>>>
>>>>
>>>> probably not worth the worry, new machines are x86_64 mostly, keep in
>>>> mind RHEL7 dropped i686 at all
>>>>
>>>> even if they are still used - 10% sounds much *but* such old machines
>>>> mostly have a special task and are far away from noticeable load and
>>>> it really depends on the workload if you even notice 20% performance
>>>> drop
>>>>
>>>> at least i doubt there is a noticeable userbase with i686 running
>>>> Fedora at all *and* would notice the drop noticeable
>>>
>>>
>>> all of the OLPC XO 1.0 and 1.5 devices are running i686 fedora, that
>>> userbase is in the millions, but would they notice  the performance
>>> drop I do not know.
>>>
>>> It would be interesting to see how performance was impacted on 32 bit
>>> arm
>>
>>
>> The address space on 32 bit is relatively small so randomization does
>> not gain much in terms of security anyway (you could bruteforce the
>> addresses in a reasonable amount of time).
>> So high cost low benefit
>
>
> don't ignore the maintainance costs for handle i686 different,

That boils down to different compiler flags not a big deal in term of
maintenance.

> take that
> into account (including bugreports with different build-flags) the benefit
> may be higher and the main question is still: how much is the *feelable and
> real* impact for the user in case of normal operations besides benchmarks

10% (number from the other mail) is a lot especially on machines that
are slow anyway. On a fast machine you might not notice a few percent
drop in general use (depends what you do though) but on a slow machine
you would. Also slower code means the cpu is busy for a longer
duration which means higher power consumption.

As for 32bit ARM it is not register starved as x86 (32bit) is but I
haven't seen any numbers on it yet. The limited size of the address
space still applies there though.


More information about the devel mailing list