app-emulation/xen-tools-4.1.0 fails to compile on amd64 with hardened toolchain because it uses custom assembler code which is not compatible with PIE Reproducible: Always Steps to Reproduce: 1. use a system with hardened/linux/amd64 profile 2. emerge =app-emulation/xen-tools-4.1.0 Actual Results: [BUILD] bin/dumpregs.o arch/i386/core/cpu.c: In function 'get_cpuinfo': arch/i386/include/bits/cpu.h:79: error: can't find a register in class 'BREG' while reloading 'asm' arch/i386/include/bits/cpu.h:79: error: can't find a register in class 'BREG' while reloading 'asm' arch/i386/include/bits/cpu.h:79: error: can't find a register in class 'BREG' while reloading 'asm' arch/i386/include/bits/cpu.h:79: error: can't find a register in class 'BREG' while reloading 'asm' arch/i386/include/bits/cpu.h:79: error: 'asm' operand has impossible constraints arch/i386/include/bits/cpu.h:79: error: 'asm' operand has impossible constraints arch/i386/include/bits/cpu.h:79: error: 'asm' operand has impossible constraints arch/i386/include/bits/cpu.h:79: error: 'asm' operand has impossible constraints make[7]: *** [bin/cpu.o] Error 1 make[7]: *** Waiting for unfinished jobs.... [BUILD] bin/gdbmach.o make[7]: Leaving directory `/var/tmp/portage/app-emulation/xen-tools-4.1.0/work/xen-4.1.0/tools/firmware/etherboot/ipxe/src' make[6]: *** [ipxe/src/bin/rtl8139.rom] Error 2 Expected Results: successfull compile emerge --info Portage 2.1.9.42 (hardened/linux/amd64, gcc-4.4.5, glibc-2.11.3-r0, 2.6.34-xen-r4-dom0 x86_64) ================================================================= System uname: Linux-2.6.34-xen-r4-dom0-x86_64-AMD_Athlon-tm-_Dual_Core_Processor_5050e-with-gentoo-2.0.2 Timestamp of tree: Sun, 27 Mar 2011 13:15:01 +0000 app-shells/bash: 4.1_p9 dev-lang/python: 2.6.6-r2, 2.7.1-r1, 3.1.3-r1 sys-apps/baselayout: 2.0.2 sys-apps/openrc: 0.8.0 sys-apps/sandbox: 2.4 sys-devel/autoconf: 2.65-r1 sys-devel/automake: 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 4.4.5 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.10 sys-devel/make: 3.81-r2 virtual/os-headers: 2.6.36.1 (sys-kernel/linux-headers) ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=k8 -O2 -pipe -fomit-frame-pointer -mno-tls-direct-seg-refs" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-march=k8 -O2 -pipe -fomit-frame-pointer -mno-tls-direct-seg-refs" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests binpkg-logs buildpkg distlocks fixlafiles fixpackages news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" FFLAGS="" GENTOO_MIRRORS="http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/ http://ftp.uni-erlangen.de/pub/mirrors/gentoo" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="acl amd64 berkdb bzip2 cli cracklib crypt cups cxx dri gdbm gpm hardened iconv justify mmx modules mudflap multilib ncurses nls nptl nptlonly offensive openmp pam pcre perl pppd python readline session sse sse2 ssl sysfs tcpd urandom xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" PHP_TARGETS="php5-3" RUBY_TARGETS="ruby18" USERLAND="GNU" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Created attachment 267409 [details, diff] Patch to fix the problem
Created attachment 267411 [details, diff] Patch for the ebuild
Created attachment 267641 [details, diff] Patch for the ebuild That ebuild patch won't work, at least for me. The file to patch is fetched during the compilation. I know my patch is not optimal: a patch script could be injected into the main Makefile in order to avoid the double emake, or whichever solution you guys can come to. But this one works for me.
(In reply to comment #3) > I know my patch is not optimal: a patch script could be injected into the main > Makefile in order to avoid the double emake, or whichever solution you guys can > come to. But that is exactly what my patch is doing. It adds a line to the file xen-4.1.0/tools/firmware/etherboot/patches/series (which is not fetched during the build) and creates the file xen-4.1.0/tools/firmware/etherboot/patches/gentoo-hardened.patch After fetching and unpacking the xen-4.1.0/tools/firmware/etherboot/ipxe/ folder the Makefile xen-4.1.0/tools/firmware/etherboot/Makefile will apply the patch. I know this is not as clean as it should be but i think it is wrong to fetch anything during the compilation so it might be a good idea to avoid this. This however is not the only thing broken with xen-4.1.0, in fact after spending a day trying to fix everything that didn't work I reverted back to xen-4.0.1. I think xen-4.1.0 and its ebuild will require a lot more work...
The patches by Ralf Glauberman fixes the problem for me (though the ebuild patch is reversed). Thanks! The double emake by Martino Dell'Ambrogio is not needed here. Regards, Milan
Created attachment 274613 [details, diff] xen patch for builing with -pie The posted patch just deactivates the cflag -pie. so the system is not hardend anymore. i tracked the problem back and the only file/binary which has problems with -pie is xen-detect. a friend and i wrote an patch for this issue. we both are no assembly experts, so could someone please test the patch? thx.
Hello Ben, as far as I can see, the patch by Ralf Glauberman only adds -nopie in xen-4.1.0/tools/firmware/etherboot/ipxe. Ralf's and my build failed in ipxe. Your patch modifies xen-4.1.0/tools/misc/xen-detect.c, so it seems to be a different place. Or am I mistaking something here? Regards, Milan
xen-4.1.0 dropped from the tree some time ago.
(In reply to comment #8) > xen-4.1.0 dropped from the tree some time ago. The same problem persists with xen-tools-4.1.1, and the same patch fixes the problem. It's time to include it in the tree...
Yes, indeed I would vote for inclusion, too. But please do not pass -nopie to the compiler because that would break the hardening on different distributions. Altering the ASM code is the better approach.
(In reply to comment #9) > The same problem persists with xen-tools-4.1.1, and the same patch fixes the > problem. It's time to include it in the tree... Mention ID numbers (found in the details link) for working patches, not "the same patch". If you make fixing a bug a riddle, you may experience delays. Please test the patch by Ben Schweikert, attachment ID 274613. It is the only approach that is a fix rather than a hack.
(In reply to comment #11) > (In reply to comment #9) > > The same problem persists with xen-tools-4.1.1, and the same patch fixes the > > problem. It's time to include it in the tree... > > Mention ID numbers (found in the details link) for working patches, not "the > same patch". If you make fixing a bug a riddle, you may experience delays. > Please test the patch by Ben Schweikert, attachment ID 274613. It is the only > approach that is a fix rather than a hack. Sorry. My bad. I was referring to Ralf Glauberman's patch (ID# 267409). While I (think I) understand the "this breaks hardening" sentiment, I also sympathize with Milan Holzäpfel's comment (#5) that this is "only" in ipxe. Of course, one might posit that 'hardened' or not is a binary property, I still feel better (and believe my system to be more "hardened") applying "-nopie" _only_ in ipxe as opposed to building the entire xen-tools package with the vanilla gcc profile, which seems to be the suggested alternative floating around on the net [http://blog.dob.sk/tag/gentoo/]. Oh, and no, unfortunately, the patch by Ben Schweikert does *NOT* fix the breakage (compilation still fails with the same symptoms). Again, as Milan points out in comment#5, xen-detect is not where the problem lies in the first place.
Hi, here is a working patch, which was worked out by Keir Fraser and was testesd by me. This is the thread on the xen mailing list: http://lists.xensource.com/archives/html/xen-devel/2011-06/msg01074.html I attached the patch. Ben
Created attachment 290109 [details] updated patch
> Oh, and no, unfortunately, the patch by Ben Schweikert does *NOT* > fix the breakage (compilation still fails with the same symptoms). Thank you. Ben Schweikert has provided attachment ID 290109 for you with an updated patch, could you test that please?
I tested the new patch (attachment ID 290109) and -as expected- the result is exactly the same: compilation breaks in building ipxe. I cannot fathom why a patch in a totally unrelated part of the tree would help solve the problem with ipxe (which looks and feels like a standalone package), but I tested it anyway. Now you know...
well that clearly beckons a build log to demo the failure point. Your description supports the notion of two separate issues. Let's get some evidence and pin this more
id=290109 by Ben Scweikert represents a sudden deviation from the root cause of the making of the bug. The initial patch is aimed at ipxe. Now I might point out that since the bug was made in March, the internal downloading that once occurred has been fixed in 4.1.1 and takes place prior to compilation. The patch id=290109 is arguably an entirely different issue, a different bug. Considering he who lodged the bug is no longer the contributor whose patches are now under consideration, it may help and hopefully not confuse the proceedings to ask Ben where and why that patch that adjusts tools/misc/xen-detect.c was suddenly the fix, remembering it came from xen-devel at xensource. a.m@freemail points out it doesn't cure ipxe building on his system. However, I cannot fathom his preference of; applying "-nopie" _only_ in ipxe as opposed to building the entire xen-tools package with the vanilla gcc profile in a prior comment. Are you seriously suggesting the ebuild should switch gcc-config selection for the building of one selected package mid compilation? Indeed, is the fix to this bug already determined in http://blog.dob.sk/tag/gentoo/ ?? Happily our dev Mr. Vroon has lent his input to this and will make some decision and provide a direction for resolution. The test failure by a.m@freemail muddies the waters, for if it had passed the patch would likely have been taken as a resolution.
To confirm, I am resisting the urge to close this bug report as "obsolete" and asking for an up to date report on 4.1.1 instead. Please post the build log to make this actionable. Should that log show that your issue is unrelated, I will be applying Ben's patch and resolving this report.
I just tried again with xen-tools-4.1.1-r5 The same error as originally reported still occurs. My patch still solves it as also reported by a.m@freemail. It still has nothing to to with Ben Schweikerts patch against xen-detect. I understand Michael Tremers objections in comment #10, fixing the asm code would in fact be the better approach, however, until someone comes up with a patch I think it is better to disable pie for a small part of the package using my patch then to break building and force users to disable hardening for the complete package manually using gcc-config. If you just do a "grep PIE /usr/portage/* -R" you will see that it is common practice for ebuilds to disable hardening for packages without even telling the user. I will add a current build.log and emerge info.
Created attachment 290347 [details] Build log for xen-tools-4.1.1-r5
Created attachment 290349 [details] emerge --info
@Ralf: Many thanks for the build.log / emerge --info! (and the original *working* patch, of course) I really should've posted logs/info along with my earlier comment... @Ian: I wasn't suggesting to switch profiles mid-ebuild. Ralf's patch passes -nopie to the compiler for the ipxe build already. (And, as he says, _unfortunately_ this practice is not uncommon.)
@Ralf; there I was thinking you were long lost and out of the equation. It appears then that the patch by Ben is indeed a deviation and is a separate issue. We had a working patch already in your 1st 2 attachments. Your build log gives us that update for 4.1.1 that was requested, despite that we were expecting it from Ben. Now it's clearer to me how it doesn't switch mid build. The dev 'wisely' decided to refrain from finalizing it. My inclination now is your initial fix.
We need to add -nopie to the etherboot/Makefile cflag but it should only applay if gcc-specs-pie from toolchain-funcs is true. The etherboot is PXE stuff and need to be fitted in roms and with PIC/PIE the code may be 25% lager and not fit in the rom.
Created attachment 290561 [details] adjusted xen ebuild
Created attachment 290563 [details] the gentoo-hardened.patch the patch for files/gentoo-hardened.patch
tested and fixed the above mentioned ebuild and patch
Fixed in xen-tools-4.1.1-r6.ebuild
