As a followup to bug #428576, PAX_KERNEXEC, in full-blown or minimal kernels makes GRUB-EFI fail to load the kernel with: error: couldn't find suitable memory target. Minimal "bad" and "good" kernel configs will be attached in the following comments. Here is a simple mini-HOWTO for setting up a QEMU UEFI environment and an ISO that will have GRUB-EFI automatically boot the kernel (start in an empty directory, nothing will be written outside the directory). The commands assume that a bzImage is ready. Required packages: + app-cdr/cdrtools-3.01_alpha07 (unstable, for -eltorito-platform efi) + sys-fs/dosfstools, sys-fs/mtools + sys-boot/grub-2.00[GRUB_PLATFORMS="efi-32 efi-64"] + app-emulation/qemu-kvm-1.0.1[QEMU_SOFTMMU_TARGETS="x86_64"] Prepare TianoCore OVMF firmware: ---------- wget -O ovmf-ia32.zip http://sourceforge.net/projects/edk2/files/OVMF/OVMF-IA32-r11337-alpha.zip/download wget -O ovmf-x64.zip http://sourceforge.net/projects/edk2/files/OVMF/OVMF-X64-r11337-alpha.zip/download mkdir -p ovmf/ia32 ovmf/x64 unzip -od ovmf/ia32 ovmf-ia32.zip unzip -od ovmf/x64 ovmf-x64.zip ln -sf OVMF.fd ovmf/ia32/bios.bin ln -sf CirrusLogic5446.rom ovmf/ia32/vgabios-cirrus.bin ln -sf /usr/share/qemu/vapic.bin ovmf/ia32/ ln -sf OVMF.fd ovmf/x64/bios.bin ln -sf CirrusLogic5446.rom ovmf/x64/vgabios-cirrus.bin ln -sf /usr/share/qemu/vapic.bin ovmf/x64/ ---------- Generate GRUB-EFI images (32- and 64-bit), embed them in an EFI El-Torito boot section, and create an ISO with the kernel: ---------- mkdir -p boot/grub EFI/BOOT cat > boot/grub/grub.cfg <<EOF set timeout=1 menuentry "Linux" { linux (cd0)/bzImage earlyprintk=serial,keep debug } EOF grub2-mkstandalone -O i386-efi -o EFI/BOOT/BOOTIA32.EFI boot/grub/grub.cfg grub2-mkstandalone -O x86_64-efi -o EFI/BOOT/BOOTx64.EFI boot/grub/grub.cfg truncate -s 5M efiboot.img mkdosfs efiboot.img MTOOLS_SKIP_CHECK=1 mcopy -i efiboot.img -sQ EFI :: mkisofs -o efi.iso -R -no-emul-boot -eltorito-platform efi -b efiboot.img efiboot.img /usr/src/linux-3.4.6-hardened-r1/arch/x86/boot/bzImage ---------- Run QEMU-KVM with OVMF firmware and logged kernel output: ---------- qemu-system-x86_64 -cpu kvm64 -L ovmf/ia32 -nodefaults -sdl -monitor vc -m 64M -vga cirrus -cdrom efi.iso -serial file:serial.log qemu-system-x86_64 -cpu kvm64 -L ovmf/x64 -nodefaults -sdl -monitor vc -m 64M -vga cirrus -cdrom efi.iso -serial file:serial.log ---------- To cleanly exit QEMU, press Ctrl-Alt-2 and type "stop", "exit".
Created attachment 319792 [details] minimal hardened-sources-3.4.6-r1 configuration, with KERNEXEC Minimal configuration for a kernel that GRUB fails to load.
Created attachment 319794 [details] minimal hardened-sources-3.4.6-r1 configuration, without KERNEXEC Minimal configuration for a kernel that GRUB successfully loads. PAX_KERNEXEC has been replaced with PAX_SEGMEXEC (since some memory execution protection must be compiled in when PAX is enabled). The configuration files are for x86 kernels.
Created attachment 319796 [details] output from non-KERNEXEC kernel with IA32 OVMF firmware This is the expected output -- GRUB loads the kernel, and it proceeds up to "init" launch failure.
Created attachment 319798 [details] output from non-KERNEXEC kernel with x64 OVMF firmware Similar output for x64 OVMF firmware.
Reducing QEMU's RAM size results in the same message for kernels that GRUB otherwise succeeds to load. However, with PAX_KERNEXEC increasing available RAM has no effect. I suspect KERNEXEC results in some build-time kernel image corruption that manifests during EFI boot, will attach a full-blown kernel output with NULL derefs soon.
Created attachment 319874 [details] output from full-blown kernel with IA32 OVMF firmware PAX_KERNEXEC is not configured, so GRUB succeeds in loading the kernel. However, there is a stream of NULL derefs, and a reboot afterwards. So my previous comment was not exact -- the image and/or memory corruption (if it is indeed the case) is apparently caused by GRKERNSEC/PAX in general, not just PAX_KERNEXEC. Kernel config to be attached in next comment.
Created attachment 319880 [details] full-blown x86 3.4.2-hardened kernel config This is the configuration that results in a stream of NULL derefs. It is for kernel 3.4.2, but the same issue is present in 3.4.6-hardened-r1 as well (just make oldconfig). Note that PHYSICAL_START==PHYSICAL_ALIGN as a (BIOS boot) workaround for bug #428576.
(In reply to comment #5) > I suspect KERNEXEC results in some build-time kernel image corruption that > manifests during EFI boot, will attach a full-blown kernel output with NULL > derefs soon. The stream of NULL derefs was apparently caused by bug #428576, and is not present anymore in hardened-sources-3.4.7. However, the original problem (PAX_KERNEXEC causing GRUB-EFI to fail with: "error: couldn't find suitable memory target.") is still present. By the way, it is possible that the problem is not only with EFI, but I don't have a setup for GRUB BIOS boot.
Comment on attachment 319874 [details] output from full-blown kernel with IA32 OVMF firmware Stream of NULL derefs is an unrelated problem that was apparently fixed in bug #428576.
Comment on attachment 319880 [details] full-blown x86 3.4.2-hardened kernel config Stream of NULL derefs is an unrelated problem that was apparently fixed in bug #428576.
Created attachment 320136 [details] hardened-sources-3.4.6-r1 config that works with kernexec and sys-boot/grub-2.00[grub_platforms_efi-64]
I just built to test on my laptop and grub2 uefi-64 is running with the kenrnel running kernexec just fine so far.
(In reply to comment #11) > Created attachment 320136 [details] > hardened-sources-3.4.6-r1 config that works with kernexec and > sys-boot/grub-2.00[grub_platforms_efi-64] Matt, I didn't look through this, but is there any subtle point that needs to be documented so others don't hit the same?
(In reply to comment #12) > I just built to test on my laptop and grub2 uefi-64 is running with the > kenrnel running kernexec just fine so far. Hi, I understand that you tested an x86_64 kernel on real hardware? This bug is about x86 in QEMU OVMF. I suspect that it's some elusive image corruption, and KERNEXEC only happens to trigger it. E.g., I have a (full-blown) kernel (without KERNEXEC) panicking, or entering an infinite loop during memtest on IA32 OVMF firmware, but not on x64 firmware. Will try to narrow that down and submit a separate bug.
the latest patches should fix the problem, although 64M is still too low but 96M worked here, i didn't bother to figure out the exact limit ;).
(In reply to comment #15) > the latest patches should fix the problem, although 64M is still too low but > 96M worked here, i didn't bother to figure out the exact limit ;). Great, will test as soon as it's released on grsecurity.net (I assume it's not the change in net/netfilter/nf_conntrack_core.c wrt. hardened-sources-3.4.7 in currently available patches, since this file is not compiled into the minimal kernel in comment #1).
(In reply to comment #15) > the latest patches should fix the problem, although 64M is still too low but > 96M worked here, i didn't bother to figure out the exact limit ;). Did you forget to update grsecurity patches? I see pax-linux-3.4.7-test28.patch from Aug 3, but grsecurity-2.9.1-3.4.7-201208021520.patch (which a I understand includes pax-linux patches) is from Aug 2. pax-linux patches are difficult to test, because hardened-sources used grsecurity patches.
(In reply to comment #17) > (In reply to comment #15) > > the latest patches should fix the problem, although 64M is still too low but > > 96M worked here, i didn't bother to figure out the exact limit ;). > > Did you forget to update grsecurity patches? i did not :). i maintain PaX, not grsecurity and spender has been away for the weekend, he'll update his patches soon. in the meantime you can just apply the interdiff to grsec, it'll work as well.
(In reply to comment #18) > (In reply to comment #17) > > (In reply to comment #15) > > > the latest patches should fix the problem, although 64M is still too low but > > > 96M worked here, i didn't bother to figure out the exact limit ;). > > > > Did you forget to update grsecurity patches? > > i did not :). i maintain PaX, not grsecurity and spender has been away for > the weekend, he'll update his patches soon. in the meantime you can just > apply the interdiff to grsec, it'll work as well. Maxim, as pipacs said, I need to wait for everything to migrate forward. I'm very much on top of things, maybe too much so! ie Have patience :)
(In reply to comment #19) > Maxim, as pipacs said, I need to wait for everything to migrate forward. > I'm very much on top of things, maybe too much so! ie Have patience :) No problem, I just thought that I am missing something obvious that no one mentions explicitly (like, e.g., some pre-release repository of patches). Now that everything is clear, I will apply an interdiff like @pageexec suggested, and test.
Created attachment 320528 [details, diff] pax patch for hardened-sources-3.4.7 (misses another grsecurity patch) I tested the interdiff with 128M RAM on both IA32 and x64 OVMF, and it fixes the bug, thanks! Less memory is apparently simply not enough for both OVMF and GRUB, e.g. -- GRUB is unable to load graphics mode in x64 (latest OVMF). The issue I mentioned in comment #14 wrt. IA32 OVMF is not gone, so will report it in a separate bug.
(In reply to comment #21) > The issue I mentioned in comment #14 wrt. IA32 OVMF is not gone, so will > report it in a separate bug. Created bug #430122.
this can be closed now.
