> Hi Niels,
> On 16.10.2016 08:45, Niels Thykier wrote:
>> Do you know if upstream has re-evaluated this choice after gcc-5 fixed
>> one of the major performance issues with PIC on i386?
> That's great! Thanks for sharing this information.
> However, in the case of ffmpeg the really performance critical part is
> optimized in hand-written assembler code, which for i386 contains text
> So the ffmpeg libraries will contain text relocations on i386 even when
> built with -fPIE/-fPIC (which will be the case in the next release, since
> pie was enabled upstream).
> By the way, do you happen to know what problems these text relocations
> cause from a security point of view?
> (I thought they were incompatible with NX, but that seems not to be
> the case .)
> Best regards,
I wish I did. For an executable, the absence if PIE makes the linker
load the binary at a fixed offset, making it very easy to determine
(some) addresses for ROP attacks.
AFAICT, for non-PIC shared-libraries the linker still has to relocate
it, but I cannot quite figure out if that method is easier to exploit or
I suspect you might be derive it from reading the following two articles:
 The PIC one mentions "lazy binding optimization" as an
(optimization) advantage. As I recall, that feature is effectively
negated when using the "relro" (default) and the "bindnow" (suggested as
a default) hardening flags.