Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 16 Feb 2014 10:43:00 -0500
From: "CERT(R) Coordination Center" <>
To: Solar Designer <>
        "CERT(R) Coordination Center" <>
Subject: Re: Vendor adoption of PIE INFO#934476 oss-security

Hash: SHA1

Hi Alexander,

Solar Designer <> 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:
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

Thank you,
   Will Dormann

Vulnerability Analyst
CERT Coordination Center
4500 Fifth Ave.
Pittsburgh, PA 15213

Version: GnuPG v1.4.5 (GNU/Linux)


Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ