[Solved] grsec modprobe: can't load module: unknown symbol

[mathias]

Hello,

I'm trying to get a grsec-enabled kernel running on a Debian 8 ("Jessie") system. However, when I try to boot the newly compiled kernel, modprobe fails to load kernel modules because it is unable to properly resolve various symbols.

Here's my setup:

The system storage is backed with a software RAID5, created using mdadm, and a dm-crypt partition holds the root file system.

Because I'm running Debian, I'd like to keep my kernel as similar to upstream as possible, minus the various patches the maintainers apply to the vanilla kernel. So, I grabbed the kernel config from Debian's "experimental" repo (currently 4.0-1~exp1) and downloaded the sources for Linux 4.0.2 and the current grsecurity patch. I then enable grsec and compile the kernel. (You can download the .config I've created from https://calenhad.com/grsec-config)

But, when I boot the new kernel I get this error:

Code: Select all

modprobe: can't load module md_mod (kernel/drivers/md/md-mod.ko): unknown symbol in module, or unknown parameter
modprobe: can't load module dm-mod (kernel/drivers/md/dm-mod.ko): unknown symbol in module, or unknown parameter


Letting the system eventually fall into an emergency shell I was able to run dmesg and see that the missing symbols were

Code: Select all

unregister_reboot_notifier

and

Code: Select all

out_of_line_wait_on_bit

, both of which do exist in the kernel.

I did find this thread viewtopic.php?f=3&t=3701&p=13376 that at least mentioned modprobe and unknown symbols. I tried disabling CONFIG_GRKERNSEC_HIDESYM in my config to see if that would fix the problem. Trying this change did allow md_mod to load, but dm-mod still fails, although with a different unresolved symbol:

Code: Select all

call_rcu_sched

.

I have verified that a plain, vanilla 4.0.2 kernel with Debian's upstream config as a base boots properly on this system. Changing to a grsec one fails.

Has anyone else run into this sort of problem before? I'd appreciate any suggestions or solutions!

[N8Fear]

My first guess would be that you are using an initrd/initramfs with outdated kernel modules that are required for booting. Did you update that initrd/initramfs after building the new kernel?
The easiest way would be just to compile everything you need to access root into the kernel image and use modules just for the later stuff (if you want to use modules at all).

[mathias]

The initrd is being updated to match the new kernel. I'm using the "deb-pkg" Makefile target when compiling the kernel, and when I install the resulting .deb the update-initramfs hook is being properly called.

I'd like to keep changes to the kernel config minimal, since that will make it easier to track Debian's upstream config changes.

[mathias]

I saw that the 4.0.2 kernel has entered Debian's unstable repo, so I grabbed that config and tried compiling the grsec patched kernel again. This time the kernel properly boots without any issues. However, I don't understand why this specific config works while a similar one doesn't. I've looked at the diff between configs, and nothing significant jumps out at me that would account for this change.

To summarize:
Linux 4.0.2 with grsec patch grsecurity-3.1-4.0.2-201505101122
This config fails to boot: https://calenhad.com/grsec-config
This config works properly: https://calenhad.com/grsec-config-good

[mathias]

Posting a follow up:

As I previously reported, using an updated 4.0.2 config + grsec boots properly. I have also been able to boot a 4.0.4 + grsec kernel. So I guess the problem is resolved for me by upgrading to the latest version of the kernel and grsec patch, which is fine, but I'm still curious as to exactly why that specific config fails to boot. I've compiled and used grsec-hardened kernels before, but I had never encountered problems loading modules at boot.