In this example a hardened build server is used for building beaglebone OE images, and qemu-arm is run during do_rootfs for a handful of post-inst scripts. The first one of the post-inst scripts to be run hangs the build without all four of the following flags disabled on qemu-arm: MPROTECT RANDEXEC EMUTRAMP RANDMMAP Looks like the last one was triggered by an madvise call, and disabling RANDMMAP made the build complete normally. Should this work? Or should we disable madvise and try re-enabling randmmap/randexec?
(In reply to Steve Arnold from comment #0) > In this example a hardened build server is used for building beaglebone OE > images, and qemu-arm is run during do_rootfs for a handful of post-inst > scripts. The first one of the post-inst scripts to be run hangs the build > without all four of the following flags disabled on qemu-arm: > > MPROTECT > RANDEXEC > EMUTRAMP > RANDMMAP > > Looks like the last one was triggered by an madvise call, and disabling > RANDMMAP made the build complete normally. Should this work? Or should we > disable madvise and try re-enabling randmmap/randexec? i dont' get disabling emutramp. that doesn't sound right. can you give a simple reduced case so i can reproduce you problems.
My test tool is bitbake/poky/meta-oe so probably not. The problem is slightly different with the latest build (effectively the same, just on a different package). Now it goes into an infinite loop with the default qemu flags when it tries to build gobject-introspection and uses qemu-arm to run the gir-scanner stuff at the end of the compile step. The workaround that works (and I tried many different combinations of flags) is add one more flag "-r", which I put in the qemu ebuild in my dev overlay so I wouldn't forget. Note the same thing happens whether bitbake uses its own qemu-native bin or I switch to ASSUME_PROVIDED and it uses the host qemu. Here's the workaround: # Disable mprotect on the qemu binaries as they use JITs to be fast #459348 pushd "${ED}"/usr/bin >/dev/null pax-mark m "${softmmu_bins[@]}" "${user_bins[@]}" => pax-mark sxr "${softmmu_bins[@]}" "${user_bins[@]}" <= popd >/dev/null I added all three above just to be explicit in what it should look like, but -r is the one that made a difference vs. the current defaults.
This hit me as well with qemu-arm.
if qemu fails with ASLR (note that i haven't seen it on amd64) then the most likely reason is that somewhere it expects MAP_FIXED behaviour without actually using MAP_FIXED in a mmap call. perhaps that's a hint to someone familiar with the code so that this can be fixed properly.
Can we please not stand on ceremony and just fix the ebuild? As is, the patches already introduce a ton of new warnings, and good luck getting them to work on non-x86. I for one don't want to touch that even with *your* stick. Just sayin... And it's still broken for me with 2.8.0 and just "m" but it can be fixed with pax-mark "mr" (is that doable as a workaround?) so qemu-arm works as expected in the case of hardened build server (of which we have 2 now).
I have applied the following change to 2.8.0-r7 and 9999: - pax-mark m "${softmmu_bins[@]}" "${user_bins[@]}" + pax-mark mr "${softmmu_bins[@]}" "${user_bins[@]}" # bug 575594 Please test. commit f732fbdd6ab148b548dce077f8581695735484d5 Author: Matthias Maier <tamiko@gentoo.org> Date: Thu Mar 9 13:06:23 2017 -0600 app-emulation/qemu: use pax-mark "mr" instead of pax-mark "m", bug #575594 Package-Manager: Portage-2.3.3, Repoman-2.3.2
