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

[Niels Thykier]

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
not.

I suspect you might be derive it from reading the following two articles[1]:

 *
http://eli.thegreenplace.net/2011/08/25/load-time-relocation-of-shared-libraries/
 *
http://eli.thegreenplace.net/2011/11/03/position-independent-code-pic-in-shared-libraries/


~Niels

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