libgstffmpeg.so is the only piece of code on my system (amd64, hardened) which contains textrels. textrels are forbidden in the kernel for security and performance reasons, hence loading libgstffmpeg.so fails, and playing videos is impossible. Is it possible to build an libgstffmpeg.so without textrels, or at least provide an use flag for optionally doing so?
textrels is not something we _enable_, either the code is poorly done or the code simply cannot work without some textrels. Either way, it's not a feature that can be controlled with a USE flag. Thanks
(Besides that it's questionable if forbidding textrels really increases security) You should give more details, on AMD64 FFmpeg itself contains only one area with textrels, and those are in the .rodata section (not .text) and can be avoided by compiling without yasm. And even for those there is a proposed patch you can try to push upstream: http://archives.free.net.ph/message/20091117.001053.e85f385a.en.html Apart from that, gstffmpeg itself might add some textrels, though I can't really imagine it.
The exact symptom is "(gnome-settings-daemon:1948): GStreamer-WARNING **: Failed to load plugin '/usr/lib64/gstreamer-0.10/libgstffmpeg.so': /usr/lib64/gstreamer-0.10/libgstffmpeg.so: cannot make segment writable for relocation: Permission denied" and e.g. swfdec not showing videos. I won't compile by hand if there is an ebuild. If there is a patch for the problem, or if the problem can be avoided by not using yasm, is there any chance to modify the gst-plugins-ffmpeg ebuild to either apply the patch or avoid yasm, at least optionally, depending on the "pic" USE flag? "pic" was introduced for exactly that purpose, and is obeyed by the ffmpeg ebuild (changing some configure options of ffmpeg), but not by the gst-plugins-ffmpeg ebuild. This is a regression w.r.t. to the old gst-plugins-ffmpeg ebuild which linked against the external ffmpeg and hence was pic-clean.
QA: other │ │QA Notice: The following files contain runtime text relocations │ │ Text relocations force the dynamic linker to perform extra │ │ work at startup, waste system resources, and may pose a security │ │ risk. On some architectures, the code may not even function │ │ properly, if at all. │ │ For more information, see http://hardened.gentoo.org/pic-fix-guide.xml │ │ Please include the following list of files in your report: │ │TEXTREL usr/lib64/libavcodec.so.52.37.1
this was for media-video/ffmpeg-0.5_p20373 - 06/23/2010 sorry for the double post all info from same error
Why don't we add a flag to use system ffmpeg instead of building our own? I made an ebuild in order to build gst-plugins-ffmpeg on my x86-hardened system. I know it's unsupported upstream, but if there's such an option why shouldn't we add system-ffmpeg useflag?
Seriously? Because it is known to break ? We don't ship things that upstream says will be broken.
On x86 hardened (and possibly amd64) gst-plugins-ffmpeg with internal ffmpeg fails to build. So, we're left either without gst-plugins-ffmpeg, either with a kinda-might-work gst-plugins-ffmpeg linked against external ffmpeg. I'm not suggesting enabling linking against system ffmpeg by default, but adding it as a masked useflag with an appropriate warning. Many things are known to break, but there's a reason for keeping --with-system-ffmpeg by upstream, isn't it? Another options is, perhaps, optionally disabling asm optimizations in gst-plugins-ffmpeg.
A couple of notes from gst-ffmpeg maintainer: * Latest gst-ffmpeg's build (0.10.10.3 pre-release) has changed slightly, we previously used to configure the internal ffmpeg as "--enable-static --enable-shared" in order to have .a/.la we could properly link into the resulting gst-ffmpeg shared library. This has changed, and we now use "--enable-static --enable-pic" which does the proper thing. Maybe this fixed your textrel issues. * We have left the option for using system-wide ffmpeg mainly because people were complaining about not being able to do so. That being said, if the system-wide ffmpeg is the same revision as the one we internally use (in ./ffmpegrev) , there shouldn't be any issues. So if you make the gst-ffmpeg ebuild require a SPECIFIC ffmpeg you should be fine.
*** Bug 337197 has been marked as a duplicate of this bug. ***
Could you please try bump your ebuild (name bump works) to lastest version of ffmpeg (i.e. 0.10.11)? For me the 0.10.9 did not pass the ebuild tests because of this problem (which seems to be a known breakage in that specific revision of ffmpeg that gst-plugins-ffmpeg uses, and apparently why it turns off mmx for darwin by default in the ./configure script). However 0.10.11 compiles and works fine on my amd64 hardened gentoo box (running gcc-4.4.4-r4 and pax).
I currently have troubles actually running gst-plugins-ffmpeg (I upgraded to a graphics card not supporting Xv, and I don't use gnash or swfdec any more), but I can confirm your observations: gst-plugins-ffmpeg 0.10.9 results in "cannot make segment writable for relocation: Permission denied", 0.10.11 does not. Also, scanelf says that libgstffmpeg.so contains textrels for 0.10.9 and is clean for 0.10.11.
Bumped to 0.10.11 which should fix this. Please reopen if you still see the problem.
