1. The problem is present in hardened-sources (with GRSECURITY / PAX on or off), but not in gentoo-sources. 2. The problem is relatively old (at least since 3.2 stabilization), and was tested on hardened-sources-3.4.7 with patch fix from bug #428726 applied. 3. The problem is unrelated to GRUB, and can be tested by enabling EFI_STUB and running the kernel directly from OVMF. For an ISO setup and OVMF download links, see first comment in bug #428726. 4. The minimal kernel configuration was tested both with released OVMF images, and images compiled from git. 5. The problem is present when CONFIG_EFI and CONFIG_ACPI are on (EFI_STUB is unrelated), and is not present on x64 OVMF. The kernel panic always ends with: [<c114b52e>] ? start_kernel+0x198/0x250 [<c114b16d>] ? repair_env_string+0x4d/0x4d but calls after start_kernel depend on the specific kernel configuration. Minimal kernel configuration and kernel panic output follow. The command used was: qemu-system-x86_64 -cpu kvm64 -L .../ia32 -nodefaults -sdl -monitor vc -m 256M -vga cirrus -hda fat:x -serial file:serial.log where directory "x" contains bzImage.efi (bzImage needs to be renamed).
Created attachment 320538 [details] minimal x86 hardened-sources-3.4.7 configuration that results in panic CONFIG_EFI_STUB=y is unrelated to the problem, and can be disabled.
Created attachment 320540 [details] serial log from QEMU
The toolchain is latest stable hardened profile one: sys-devel/gcc-4.5.3-r2 was built with the following: USE="cxx hardened nls nptl openmp (-altivec) -bootstrap -build -doc (-fixed-point) -fortran -gcj -graphite -gtk (-libssp) -lto -mudflap (-multilib) -multislot -nocxx -nopie -nossp -objc -objc++ -objc-gc -test -vanilla" sys-devel/binutils-2.21.1-r1 was built with the following: USE="cxx nls zlib -multislot -multitarget -static-libs -test -vanilla" CFLAGS="-O2 -march=pentium3 -mtune=core2 -pipe" CXXFLAGS="-O2 -march=pentium3 -mtune=core2 -pipe"
thanks for the report, i fixed the bug in the latest patches, grsec will follow later today i guess.
Created attachment 320566 [details, diff] interdiff patch fixing the problem (pax-linux-3.4.7-test28 -> 29) I tested on both IA32 and x64 OVMF, with a minimal and a full-blown kernel, and the problem seems to be fixed, thanks! So it was KERNEXEC again, after all. By the way, I think that this time you forgot to upload the patches, I took -test29 from ~paxguy1.
i guess this one can be closed now ;).
