Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 216666

Summary: crypto++, mplayer and amule should be masked for hardened profile
Product: Gentoo Linux Reporter: Paul Osmialowski <newchief>
Component: Current packagesAssignee: The Gentoo Linux Hardened Team <hardened>
Status: RESOLVED CANTFIX    
Severity: blocker    
Priority: High    
Version: unspecified   
Hardware: x86   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---

Description Paul Osmialowski 2008-04-07 09:01:09 UTC
Both of these components suffer from the same compilation time error which looks like that:
i686-pc-linux-gnu-g++ -O2 -march=pentium4 -fstack-protector -c vmac.cpp
vmac.cpp: In member function `void CryptoPP::VMAC_Base::VHASH_Update_SSE2(const CryptoPP::word64*, size_t, int)':
vmac.cpp:367: error: can't find a register in class `GENERAL_REGS' while reloading `asm'
make: *** [vmac.o] Error 1
I've found this message:
http://groups.google.pl/group/linux.gentoo.user/browse_thread/thread/45f5242a2837d1e/e4489e3033682915?lnk=st&q=gentoo+error%3A+can%27t+find+a+register+in+class+%60GENERAL_REGS%27+while+reloading+%60asm%27#e4489e3033682915
This suggests these packages will never be able to be compiled in hardened profile and therefore both should be masked.
Since latest amule daemon uses crypto++, latest version of amule should also be masked!


Reproducible: Always

Steps to Reproduce:
1. Install hardened gentoo with SSP
2. emerge --sync
3. emerge crypto++ amule mplayer

Actual Results:  
i686-pc-linux-gnu-g++ -O2 -march=pentium4 -fstack-protector -c vmac.cpp
vmac.cpp: In member function `void CryptoPP::VMAC_Base::VHASH_Update_SSE2(const CryptoPP::word64*, size_t, int)':
vmac.cpp:367: error: can't find a register in class `GENERAL_REGS' while reloading `asm'
make: *** [vmac.o] Error 1

Expected Results:  
merged packages
Comment 1 Gordon Malm (RETIRED) gentoo-dev 2008-04-07 20:52:31 UTC
mplayer works fine @ runtime on hardened given mprotect is not enforced on the binary.  Concerning compile, a simple workaround is to compile with nopie gcc specs profile.  Yeah it smells, but these aren't the only packages needing this workaround, so we might as well mask all the others too if this is the road to be traveled.

Therefore I would vote against masking and resolve as WONTFIX/INVLAID or a duplicate of one of the following bugs:

bug 93862, bug 133586, bug 175627 or bug 184003

A separate bug should be opened for the fixing of crypto++.  If it lingers forever too then so be it.
Comment 2 solar (RETIRED) gentoo-dev 2008-04-07 21:25:02 UTC
mplayer will never be p.masked in hardened profiles
Comment 3 Paul Osmialowski 2008-04-08 08:12:49 UTC
mplayer compile time bug (hardened profile):
i686-pc-linux-gnu-gcc -I../libavcodec -I../libavformat -Wdisabled-optimization -Wdeclaration-after-statement -I. -I.. -I../libavutil -Wall -Wno-switch -Wpointer-arith -Wredundant-decls -O4 -march=pentium4 -mtune=pentium4 -pipe -ffast-math -fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -DHAVE_CONFIG_H -I/usr/X11R6/include -I/usr/include/ -I/usr/include/SDL  -D_REENTRANT   -I/usr/include/freetype2 -I/usr/include -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng12     -c -o vf_decimate.o vf_decimate.c
vf_decimate.c: In function `diff_MMX':
vf_decimate.c:26: error: can't find a register in class `BREG' while reloading `asm'
make[1]: *** [vf_decimate.o] Error 1
make[1]: Leaving directory `/tmp/portage/media-video/mplayer-1.0_rc2_p25993/work/mplayer-1.0_rc2_p25993/libmpcodecs'
make: *** [libmpcodecs/libmpcodecs.a] Error 2

compile time flags were:
USE="X a52 aac aalib alsa amrnb amrwb bidi bl cdparanoia dga dts dv enca encode esd ftp ggi gif gtk iconv ipv6 jack jpeg ladspa libcaca live lzo mad md5sum mmx mp2 mp3 musepack nas openal opengl oss png pnm quicktime rar real sdl speex srt sse sse2 tga theora tivo truetype unicode vidix vorbis win32codecs x264 xanim xv xvid xvmc -3dnow -3dnowext (-altivec) -arts -bindist -cddb -cdio -cpudetection -custom-cflags -debug -directfb -doc -dvb -dvd -fbcon -joystick -lirc -livecd -mmxext -nemesi -pulseaudio -radio -rtc -samba (-ssse3) -svga -teletext -v4l -v4l2 -xinerama -xscreensaver -zoran" VIDEO_CARDS="-mga -s3virge -tdfx -vesa"


With USE="-mmx -sse -sse2" compilation stops in different place:
i686-pc-linux-gnu-gcc -I../libswscale -I../libavcodec  -DHAVE_AV_CONFIG_H -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_ISOC9X_SOURCE -I.. -I.. -I../libavutil -Wdisabled-optimization -Wdeclaration-after-statement -I. -I.. -I../libavutil -Wall -Wno-switch -Wpointer-arith -Wredundant-decls -O4 -march=pentium4 -mtune=pentium4 -pipe -ffast-math -fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -DHAVE_CONFIG_H -I/usr/X11R6/include -I/usr/include/ -I/usr/include/SDL  -D_REENTRANT   -I/usr/include/freetype2 -I/usr/include -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng12    -c -o h264.o h264.c
cabac.h: In function `get_cabac_noinline':
cabac.h:529: error: PIC register `%ebx' clobbered in `asm'
make[1]: *** [h264.o] Error 1
make[1]: Leaving directory `/tmp/portage/media-video/mplayer-1.0_rc2_p25993/work/mplayer-1.0_rc2_p25993/libavcodec'
make: *** [libavcodec/libavcodec.a] Error 2
So I've tested also USE="-mmx -sse -sse2 -x264" but no change, still it tries to compile h264.c which ends with error in cabac.h
Comment 4 Gordon Malm (RETIRED) gentoo-dev 2008-04-08 21:48:03 UTC
The workaround is to switch to hardenednopie gcc specs, compile, then switch back.
Comment 5 kfm 2008-04-13 01:23:14 UTC
The crypto++ issue is already the subject of bug 215211. Furthermore, the mplayer issue is the subject of bug 175627.

But this bug isn't merely reporting issues, it's issuing a request to package.mask the affected packages. In that light, I see no choice but to close this as CANTFIX ("is not solvable in any reasonable fashion") because the hardened team will clearly never honour such a request on the basis that it is not reasonable.

The explanation for this is simple: "we don't mask everything when it does not build. We try and fix the things that are worth fixing". In other words, if we package.mask everything that requires a workaround (or simply integrate compile hacks such as "-fno-PIC") then we are de-incentivising people to actually fix these issues in the most technically correct manner.

On the other hand, we are well aware that it is an inconvenience to have to use workarounds until things actually are fixed. I can only suggest that the author use a custom eclass in an overlay or a custom .bashrc in order to automatically disable PIC for the affected package(s). This is the route that some other users have taken, as evidenced by http://bugs.gentoo.org/show_bug.cgi?id=175627. Any contributions in terms of resolving the incompatibilities with PIC should go to the relevant bugs themselves, as noted above.
Comment 6 Wolfram Schlich (RETIRED) gentoo-dev 2008-04-24 08:28:31 UTC
Also see bug #217907 ...