On Fri, Jan 9, 2015 at 12:44 AM, Reindl Harald <h.reindl(a)thelounge.net> wrote:
Am 09.01.2015 um 00:35 schrieb drago01:
>
> On Fri, Jan 9, 2015 at 12:16 AM, Dennis Gilmore <dennis(a)ausil.us> wrote:
>>
>> On Thu, 08 Jan 2015 20:25:36 +0100
>> Reindl Harald <h.reindl(a)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.