grsecurity forums

Until now I successfully used grsec with the 3.2.60 linux libre kernel. After compiling the 3.14.12 kernel with grsec, the system freezes at the beginning of the boot process. If I exclude grsec during the compilation, the 3.14.12 kernel works fine. What can I do to investigate the possible cause of this behaviour?

Edit:
I don't know if it's important to know: For the 3.14.12 kernel I used the old config with
yes "" | make oldconfig
I also use ecryptfs.

1. does vanilla 3.14.12 work? (or was that what you meant by 'exclude grsec''?)
2. assuming it does, you should take that config and do an oldconfig on the grsec kernel based on it.
3. can you capture the kernel boot log somehow (netconsole/serial console)?
4. does the kernel fail to boot in qemu as well? in that case you could send us the usual files and we can investigate this ourselves.
5. if a patched kernel works with all grsec features disabled then you could also try to do a binary search for the option that triggers the boot failure, but that'll take some time.

1. Yes
2. I used the same config.
Once I disabled grsec by using "make menuconfig" and excluding "Grsecurity", i.e. "[]" --> Everything works
Once I enabled grsec in the same config --> It freezes at the beginning of the boot process
I tried to disable only mprotect and I also tried the deb's you provided via twitter: https://grsecurity.net/~spender/deb_packages
Both without success
Maybe you have a guest which feature of grsec is responsible for the freezing, so I can try out?
3. I used netconsole but the system freezes so early that I received no log messages.
4. Qemu will be my next step
5. I have no idea how to do a binary search, sorry.

how early does the boot freeze happen? is there anything printed on the screen? can you perhaps take a photo? in any case, you can start by disablig gcc plugin based features (if you used them at all), and if you boot with UEFI then try to disable KERNEXEC and UDEREF. other features should not affect early boot code this badly but we'll see . as for the binary search, it's just an optimal strategy to reduce the number of configs you have to try to narrow down the culprit option, don't worry about it. also if you publish your config i can try it in qemu myself.

The freezing happens so early that nothing is printed on the screen.
I have nailed down the problem to the feature "Enforce non-executable kernel pages". I boot with UEFI. If I exclude the feature "Enforce non-executable kernel pages", my system boots up. Is this feature important? (Until now I had no time to try qemu.)
An additional problem I encountered now is that my wireless usb adapter doesn't work any more with the 3.14.12 kernel + grsec. Do you have any idea what feature could cause this problem?

can you try to boot a KERNEXEC enabled kernel with efi=old_map (or disable CONFIG_EFI_RUNTIME_MAP in .config) and see if it helps? (there's a known issue with this EFI map code and KERNEXEC)

as for the usb/wifi problem, do you get any kernel logs? do you enable KSTACKOVERFLOW?

"efi=old_map" fixed the freezing during the boot process. Thanks! Do you still need the config or something else, so no one else has to suffer from this kind of problem in the future?

The problem of my wireless usb adapter has nothing to do with grsecurity. Sorry to bother you about this!

no need for your config however you could post the machine model + bios version so that other users can find this thread and the workaround.

The boot problem occured on a Lenovo Thinkpad x230i with the UEFI BIOS version G2ET97WW (2.57) and the UEFI BIOS Date 2013-10-25.

Solution: Adding "efi=old_map" in /etc/default/grub, i.e.
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash efi=old_map"