F22 System Wide Change: Harden all packages with position-independent code
Reindl Harald
h.reindl at thelounge.net
Fri Jan 9 12:05:21 UTC 2015
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>
More information about the devel
mailing list