I am getting an error when trying to compile VirtualBox on my hardened gentoo system: --- snip --- kmk_builtin_rm -f -- /var/tmp/portage/app-emulation/virtualbox-5.1.4/work/VirtualBox-5.1.4/out/linux.amd64/release/obj/VBoxAPIWrap/dtrace/dtrace/VBoxAPI.h.dep /var/tmp/portage/app-emulation/virtualbox-5.1.4/work/VirtualBox-5.1.4/out/linux.amd64/release/obj/VBoxAPIWrap/dtrace/dtrace/VBoxAPI.h /var/tmp/portage/app-emulation/virtualbox-5.1.4/work/VirtualBox-5.1.4/out/linux.amd64/release/obj/VBoxTpG/VBoxTpG -64 -h --host-64-bit --ring-3-context -o "/var/tmp/portage/app-emulation/virtualbox-5.1.4/work/VirtualBox-5.1.4/out/linux.amd64/release/obj/VBoxAPIWrap/dtrace/dtrace/VBoxAPI.h" -s "/var/tmp/portage/app-emulation/virtualbox-5.1.4/work/VirtualBox-5.1.4/out/linux.amd64/release/obj/VBoxAPIWrap/VBoxAPI.d" kmk: *** [/var/tmp/portage/app-emulation/virtualbox-5.1.4/work/VirtualBox-5.1.4/out/linux.amd64/release/obj/VBoxAPIWrap/dtrace/dtrace/VBoxAPI.h] Error 1 kmk: *** Waiting for unfinished jobs.... /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: /var/tmp/portage/app-emulation/virtualbox-5.1.4/work/VirtualBox-5.1.4/out/linux.amd64/release/lib/RuntimeBldProg.a(ldrkStuff.o): warning: relocation in readonly section `.rodata' /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: warning: creating a DT_TEXTREL in a shared object. /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: /var/tmp/portage/app-emulation/virtualbox-5.1.4/work/VirtualBox-5.1.4/out/linux.amd64/release/lib/RuntimeBldProg.a(ldrkStuff.o): warning: relocation in readonly section `.rodata' /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: warning: creating a DT_TEXTREL in a shared object. kmk_builtin_append -n "/var/tmp/portage/app-emulation/virtualbox-5.1.4/work/VirtualBox-5.1.4/out/linux.amd64/release/obj/VBoxManage/VBoxManageModifyVM.o.dep" "" "/var/tmp/portage/app-emulation/virtualbox-5.1.4/work/VirtualBox-5.1.4/src/VBox/Frontends/VBoxManage/VBoxManageModifyVM.cpp:" "" kmk: *** Exiting with status 2 --- snip --- I've attached the emerge --info '=app-emulation/virtualbox-5.1.4::gentoo'. Cheers, Sarah
Created attachment 443676 [details] emerge --info '=app-emulation/virtualbox-5.1.4::gentoo'
You've got a few things going on here that makes it difficult to pinpoint. You're using binutils-2.26.1, gcc-5.4.0 which are both ~arch right now, and virtualbox-5.1.4 which isn't in the gentoo tree. Until the rest of the tree catches up with this, its hard to narrow the problem. My first guess is that its binutils-2.26.1 which drops pt-pax flags, but I can't be sure. Can you give me any more clues that narrows what changed?
*** This bug has been marked as a duplicate of bug 588750 ***
Hey Anthony, thank you for the reply. Yes, you are right, it's ~amd64 here with binutils 2.26.1 and gcc-5.4.0. What else do you need so i can help you here? Cheers, Sarah
The new no-pie patch need some more fix.
(In reply to Magnus Granberg from comment #5) > The new no-pie patch need some more fix. Ah okay, it sounds like some assembly+pie problem.
Ok, been bitten by the same bug (gcc 5.4.0, binutils 2.26.1, virtualbox 5.1.4, hardened-sources 4.7.2). After a bit of digging, I'm not sure it really is a duplicate of #588750. The failing command is this: /var/tmp/portage/app-emulation/virtualbox-5.1.4/work/VirtualBox-5.1.4/out/linux.amd64/release/obj/VBoxTpG/VBoxTpG -64 -h --host-64-bit --ring-3-context -o "/var/tmp/portage/app-emulation/virtualbox-5.1.4/work/VirtualBox-5.1.4/out/linux.amd64/release/obj/VBoxAPIWrap/dtrace/dtrace/VBoxAPI.h" -s "/var/tmp/portage/app-emulation/virtualbox-5.1.4/work/VirtualBox-5.1.4/out/linux.amd64/release/obj/VBoxAPIWrap/VBoxAPI.d" It triggers this message in `dmesg`: grsec: denied RWX mmap of <anonymous mapping> by /var/tmp/portage/app-emulation/virtualbox-5.1.4/work/VirtualBox-5.1.4/out/linux.amd64/release/obj/VBoxTpG/VBoxTpG[VBoxTpG:22872] uid/euid:250/250 gid/egid:250/250, parent /usr/bin/kmk[kmk:22814] uid/euid:250/250 gid/egid:250/250 So it looks like a grsec problem. Indeed if I do this: paxctl-ng -mv /var/tmp/portage/app-emulation/virtualbox-5.1.4/work/VirtualBox-5.1.4/out/linux.amd64/release/obj/VBoxTpG/VBoxTpG Then afterwards the build trundles along for some time and fails again on these commands: /var/tmp/portage/app-emulation/virtualbox-5.1.4/work/VirtualBox-5.1.4/out/linux.amd64/release/obj/USBIdDatabaseGenerator/USBIdDatabaseGenerator -o "/var/tmp/portage/app-emulation/virtualbox-5.1.4/work/VirtualBox-5.1.4/out/linux.amd64/release/obj/VBoxSVC/USBIdDatabase.cpp" /var/tmp/portage/app-emulation/virtualbox-5.1.4/work/VirtualBox-5.1.4/src/VBox/Main/src-server/usb.ids /var/tmp/portage/app-emulation/virtualbox-5.1.4/work/VirtualBox-5.1.4/src/VBox/Main/src-server/custom.ids /var/tmp/portage/app-emulation/virtualbox-5.1.4/work/VirtualBox-5.1.4/out/linux.amd64/release/obj/VBoxCPP/VBoxCPP -d -D VBOX_FOR_DTRACE_LIB -D VBOX_FOR_DTRACE_LIB_AMD64 -D IN_RING0 -D RT_C_DECLS_BEGIN= -D RT_C_DECLS_END= -D 'RCPTRTYPE(a_Type)=RTRCPTR' -D 'R3PTRTYPE(a_Type)=RTR3PTR' -D 'R0PTRTYPE(a_Type)=a_Type' -D 'AssertCompile(a_Expr)=' -D 'AssertCompileSize(a_Stuct, a_Size)=' -D 'bool=uint8_t' -D 'VBOX' -D 'VBOX_OSE' -D 'VBOX_WITH_64_BITS_GUESTS' -D 'VBOX_WITH_REM' -D 'VBOX_WITH_RAW_MODE' -D 'RT_OS_LINUX' -D '_FILE_OFFSET_BITS=64' -D 'RT_ARCH_AMD64' -D '__AMD64__' -D 'VBOX_IN_VMM' -D 'VBOX_WITH_2ND_IEM_STEP' -D 'VBOX_WITH_3RD_IEM_STEP' -D 'VBOX_WITH_REM' -D 'VBOX_WITH_MULTI_CORE' -D 'VBOX_WITH_VMMR0_DISABLE_LAPIC_NMI' -D 'VBOX_WITH_PCI_PASSTHROUGH' -D 'VBOX_WITH_DTRACE_RC' -D 'VBOX_WITH_SAFE_STR' -D 'VBOX_WITH_RAW_RING1' -D 'VBOX_WITH_NEW_APIC' -D 'VBOX_WITH_NEW_IOAPIC' -D 'HC_ARCH_BITS=64' -D 'GC_ARCH_BITS=64' /var/tmp/portage/app-emulation/virtualbox-5.1.4/work/VirtualBox-5.1.4/include/VBox/vmm/vm.h /var/tmp/portage/app-emulation/virtualbox-5.1.4/work/VirtualBox-5.1.4/out/linux.amd64/release/obj/VMMLibDTrace/vm.d Again, those trigger similar `dmesg` messages, and disabling MPROTECT for these binaries allows the build to complete. What would a proper fix to this issue look like?
(In reply to Quentin Minster from comment #7) > > What would a proper fix to this issue look like? We'd have to identify which executables are causing the PaX violation during the build and use /usr/sbin/paxmark.sh from the sys-apps/elfix package to change the pax flags at the correct points in the ebuild. You might need to go deeper and patch the build system to invoke the script from the Makefile.
Created attachment 446500 [details, diff] virtualbox-5.1.4-ebuild-paxmark-fix.patch Here is the quick and dirty version of the fix: just build in two passes and paxmark the needed binaries in-between. The patched ebuild builds fine on my machine. I'm still working on a cleaner version that would patch the build system rather than the ebuild. However it's not easy (at least with my current understanding) as a *lot* of the interesting logic in the build system is actually hidden away in /usr/share/kBuild (from dev-util/kbuild) and overrides the logic in VirtualBox's source kBuild/ directory, and therefore can't be patched. :(
Created attachment 447022 [details, diff] virtualbox-5.1.4-paxmark-bldprogs.patch This is a somewhat cleaner solution that fixes the build system instead of working around it. It's quite dumb: just paxmark the needed binaries any time they're called. I tried but couldn't find how to paxmark the binaries just once, except in the degenerate case where MAKEOPTS=-j1. When the build system goes parallel, then the binaries may be built as a prerequisite of any .d file, and there doesn't seem to be any room for me to add a prerequisite or recipe for doing the paxmarking (that's hidden inside dev-util/kbuild). So I patch all the recipes invoking the binaries and do the paxmarking there. This patch has been tested to work with both =app-emulation/virtualbox-5.1.4 and =app-emulation/virtualbox-5.1.6, on MAKEOPTS=-j1 and MAKEOPTS=-j8. When applying it from the ebuild, a dependency should be added for sys-apps/elfix (or some USE/profile test before applying the patch?).
I can compile virtualbox. You can close this ticket.
Bug still present on my system as of virtualbox-5.1.8 with (hardened-sources-4.7.5, gcc-5.4.0, binutils-2.26.1). Proposed patch virtualbox-5.1.4-paxmark-bldprogs.patch still fixing it. What's the best way forward from here on? If this patch doesn't break the build for anybody and fixes it for some, perhaps it should make it in the tree.
I can also compile VirtualBox now. gcc (Funtoo Hardened 4.9.3-r3, pie-0.6.4) 4.9.3 vbox 5.1.8_Gentoor111374
This bug is the same as https://bugs.gentoo.org/show_bug.cgi?id=598132 While the problem is still alive with version 5.1.10., the patch works excellent with virtuabox-5.1.10, gcc 5.4, and hardened-sources 4.8.12. @ Quentin Mintser: Thanks a lot! PS: It seems reasonable to me, to include the patch in the tree.
Problem still alive with virtualbox-5.1.12 Problem still solvable with the patch.
Created attachment 463680 [details, diff] patch for ebuild and metadata.xml Patch for ebuild and metadata.xml for use of the paxmark-bldprogs.patch
Fixed in commit 2133ca0baf659da8abfe799894f8e33699f8637f Thanks for the help
