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. _______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
