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

[Reindl Harald]

Am 09.01.2015 um 12:54 schrieb Jakub Jelinek:
> On i?86 it isn't around 10%, but more like 10%-30%.

i doubt that it's always 30% - real workloads matter not worst cases and 
what are the 100% - if 100% is below a second 30% don't matter - there 
are millions of tasks where even 50% would not matter

what you also ignore is that most tasks are already in DSO libraries and 
the executeable binaries itself are only a small part these days

however, i686 is a dying architecture, otherwise RHEL would not have 
stopped tu support it at all and i personally did not see any i686 
machine in the past 6 years

> That said, even on x86_64 it isn't anything close to no overhead.
> Tried last night to rebuild GCC's cc1plus as -fpie -pie, and then
> rebuild stage3 of GCC with make -j1 separately with the original stage3
> cc1plus (ET_EXEC binary) and PIE cc1plus (ET_DYN).  The build (which
> included still time for various other tools being not PIE, make, ld, as)
> got 2.1% slower user time.  Also, the number of relocations and
> memory consumption got up.
> Non-PIE cc1plus:
> Relocation section '.rela.dyn' at offset 0x187d30 contains 190 entries:
> Relocation section '.rela.plt' at offset 0x188f00 contains 284 entries:
> GNU_RELRO      0x1d14730 0x0000000002314730 0x0000000002314730 0x0058d0 0x0058d0 R   0x1
> PIE cc1plus:
> Relocation section '.rela.dyn' at offset 0x187d90 contains 75803 entries:
> Relocation section '.rela.plt' at offset 0x344018 contains 230 entries:
> GNU_RELRO      0x1e18cf0 0x0000000002018cf0 0x0000000002018cf0 0x10e310 0x10e310 R   0x1
>
> That means e.g. on the startup of each cc1plus process, that means 1MB extra
> COW wastage (executable has 24KB of pages written and then made
> non-writable, while PIE over 1MB)

that may all be true while 2% don't impress me that much

*but* since *mobile phones* and other operating systems in the meantime 
are full PIE and it improves security how can someone justify the reason 
performance on a desktop/server distribution with much more powerful 
hardware?


-------------- 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/af929d54/attachment.sig>