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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ