Bug#528080: ffmpeg-debian: ffmpeg still has shlib-with-non-pic-code lintian errors

Niels Thykier niels at thykier.net
Sun Oct 16 11:31:00 UTC 2016

Andreas Cadhalpun:
> 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?
>> Source:
>> https://software.intel.com/en-us/blogs/2014/12/26/new-optimizations-for-x86-in-upcoming-gcc-50-32bit-pic-mode
> 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
> relocations.
> 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).

Ok. :)

> 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 [1].)
> Best regards,
> Andreas
> [...]

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[1]:



[1] 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.

More information about the pkg-multimedia-maintainers mailing list