[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 16 Feb 2014 10:43:00 -0500
From: "CERT(R) Coordination Center" <cert@...t.org>
To: Solar Designer <solar@...nwall.com>
CC: oss-security@...ts.openwall.com,
"CERT(R) Coordination Center" <cert@...t.org>
Subject: Re: Vendor adoption of PIE INFO#934476 oss-security
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Alexander,
Solar Designer <solar@...nwall.com> writes:
>
>With bzip2, the irony is that most(?) distros incur this performance
>impact anyway, because most processing occurs in libbz2, which is
>typically linked to bzip2 dynamically, and the dynamic library is built
>as PIC (should be same performance impact as PIE).
Yeah, this is something that I was thinking about early on in my
research here. There seems to be reluctance to adopt PIE in a more
widespread manner, yet it seems that real-world applications (as
opposed to synthetic benchmarks) are doing plenty of work in DSOs, so
therefore are *already* feeling the PIC performance hit.
e.g. the Ogg Vorbis example from Wikipedia:
<http://en.wikipedia.org/wiki/File:Ogg_vorbis_libs_and_application_dia.svg>
At least for this particular case, it looks like libs are where the
work happens, and the program is just a frontend.
>I'd expect nearly zero performance impact for x86_64. The paper says
>there's "average overhead of 3.61% and a geometric mean of 2.34%", but
>given this arch's PC-relative addressing it is unclear to me where the
>impact is coming from. Having manually changed some x86_64 assembly
>code in JtR -jumbo from absolute to PC-relative addressing, I saw no
>performance impact at all (although I tested only on a handful of CPU
>types) - and this is for 100% CPU-bound code. Is gcc doing something
>dumb, or are there CPUs where PC-relative addressing has performance
>impact, or is it indirect effect via code size increase (did it
>increase? why? IIRC, it didn't for me), or was the test flawed?
Based on some responses I've received so far, I'm getting the
impression that the current gcc toolchain perhaps isn't set up in a
way to to PIE in an optimal manner. But I don't have enough low-level
understanding of this stuff to confirm or deny that. See in
particular:
<https://lists.fedoraproject.org/pipermail/devel/2013-April/181062.html>
Thank you,
Will Dormann
=============================
Vulnerability Analyst
CERT Coordination Center
4500 Fifth Ave.
Pittsburgh, PA 15213
1-412-268-7090
=============================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iQEVAwUBUwDgtkFiFe3xVPtiAQL77QgAss/HXNL9yfzNszbPbx7SJvBcLSwKNyLW
yjQOngLEN97gVINfEVjhVKsM7oEsTgtKj7BiE4AITbYhAoftYudTE0EDI7+e2XUC
GiAELYcQgKn1hPq7R5zo/Dgaoz3Zg0groK/GIv/jf9AnnoTRKeVwDnYVkzn/EU8B
gad859Ow7TSK4Py9eADH18mksLPKZpDGwjNSG04YiJqAOYokiyUvLUpn6HPTKVtF
dznEWmPMlIxeR68xEei6XlpoDVQkc7k/pqqU4GU7AImhA3D5AZdWwQRsee/+bYRN
P/zTDViyiQX0l13Gb9vuyzjNgbrIAoAUTCbXwC9AhgPiekliCzLhrA==
=FfdX
-----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
