|
Message-Id: <201402161601.s1GG1KfQ021151@eton.blue.cert.org> 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.