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

[Reindl Harald]

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, 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20150109/aca2f8c4/attachment.sig>