Follow @Openwall on Twitter for new release announcements and other news
[<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

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.