Linux Kernel Runtime Guard (LKRG) - Linux Kernel Runtime Integrity Checking and Exploit Detection


1 Like

Nobody in that thread even read past the first few lines…

1 Like

Very few of the commenters indeed looks like. Following links, let alone reading footnotes, using search engines… Didn’t notice much of that there.

1 Like

Welcome to reddit :smiley:

1 Like

LKRG can cause this:

sudo iptables --list

iptables/1.8.2 Failed to initialize nft: Protocol not supported


1 Like

That setting seems pointless anyway as the Debian kernel doesn’t even have usermode helpers enabled.

1 Like

Bug on Qubes, Debian buster.

cat /proc/version

Linux version 5.3.0-0.bpo.2-amd64 (debian-kernel@… (gcc
version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 5.3.9-2~bpo10+1 (2019-11-13)

cat /proc/cmdline

BOOT_IMAGE=/boot/vmlinuz-5.3.0-0.bpo.2-amd64 root=/dev/xvda3 ro
xen_scrub_pages=0 root=/dev/mapper/dmroot console=hvc0 console=tty0
swiotlb=8192 noresume intel_iommu=on amd_iommu=on slab_nomerge
slub_debug=FZ init_on_alloc=1 init_on_free=1 mce=0 pti=on mds=full,nosmt
vsyscall=none page_alloc.shuffle=1

[0x8daa4a39f8ae8401] and should be [0x25ed90ca36ee0266] !!!
[p_lkrg] ALERT !!! MODULE’S <nf_nat> HASH IS DIFFERENT it is
[0x3d9dae4aaff5f86d] and should be [0xd8e509a7b4d09682] !!!
[p_lkrg] ALERT !!! MODULE’S <nf_conntrack> HASH IS DIFFERENT it is
[0xfe2e9cd1fd5ea173] and should be [0x99dd56638030bb2b] !!!
[p_lkrg] ALERT !!! MODULE LIST HASH IS DIFFERENT !!! - it is
[0x333c093b7373b41b] and should be [0xd42a3b20e4da8541] !!!
[p_lkrg] ALERT !!! MODULE KOBJ HASH IS DIFFERENT !!! - it is
[0x5f13310a27d2344f] and should be [0xbf5da19a4b5e9f8d] !!!
[p_lkrg] [KOBJ] ALERT !!! MODULE’S <nf_conntrack> HASH IS DIFFERENT it
is [0xfe2e9cd1fd5ea173] and should be [0x99dd56638030bb2b] !!!
[p_lkrg] [KOBJ] ALERT !!! MODULE’S <nf_nat> HASH IS DIFFERENT it is
[0x3d9dae4aaff5f86d] and should be [0xd8e509a7b4d09682] !!!

reported upstream:


Couldn’t write ‘0’ to ‘lkrg/clean_message’, ignoring: No such file or directory


Any reference for that? Asking because then I can add that to Linux Kernel Runtime Guard (LKRG) for Debian, Whonix, Qubes, Kicksecure.

1 Like

Actually, I was wrong. I was thinking of a static usermodehelper which is different from usermodehelpers in general.


Possible to load LKRG through systemd-modules-load.service / /usr/lib/modules-load.d / /etc/modprobe.d as last module?


LKRG complains about battery being automatically unload


Thanks to @madaidan for posting this on telegram.

In case anyone wondering: no, I don’t think this speaks against LKRG. This was expected. As per Linux Kernel Runtime Guard (LKRG) for Debian, Whonix, Qubes, Kicksecure LKRG quote

LKRG renders whole classes of kernel exploits ineffective

read more

Still applies.


1 Like

A blocker for installation onf LKRG by default in Non-Qubes-Whonix Whonix-Gateway:

I experienced the VM freezing during LKRG installation. Freezes GUI (seconds counter at the clock freezes and will never move on again.) Happening in a VirtualBox VM during LKRG DKMS compilation with 768 MB RAM and 512 MB swapfile. Not always reproducible. I provided various SysRq output to LKRG upstream in private e-mail. Not sharing here as it might contain sensitive information about my system.

While swap gets used, swap does not run out of memory. Check in another console tab using:

while true ; do free -m && sleep .2 ; done

Gathered the log using a serial console. Journal does not have anything interesting.

This doesn’t happen when increasing RAM. Whonix-Gateway VirtualBox by default comes with 768 MB RAM and a 512 MB encrypted swapfile. Whonix-Workstation VirtualBox by default comes 2048 MB RAM and no swapfile. (By adding >= 2000 MB RAM to Whonix-Gateway, no swap file will be created by swap-file-creator (Whonix github project). I’d very much like to increase default RAM of Whonix-Gateway to 2048 MB RAM but that won’t work out of the box for many of Whonix users. Let’s say someone has host system with 4 GB RAM which is quite common. Hard to run two VMs there. Kernel Samepage Merging (KSM) might be available for VirtualBox too, but there were some security issues with it. Some references.

LKRG compilation should be possible even though swap is required? Maybe LKRG isn’t the cause but only the trigger? 768 MB RAM for a Debian VM with XFCE might be too little RAM nowadays?

It could be this bug - a long standing kernel bug related to system stress and swap:

A bug which might not be fixed anytime soon. That would be a blocker for Non-Qubes-Whonix Whonix-Gateway LKRG installation by default. Then LKRG could could be installed by default in Non-Qubes-Whonix Whonix-Workstation. (LKRG in Qubes-Whonix has its own blockers for installation by default.)

Maybe another hack could be to install the LKRG package by default but only attempt to actually compile it if enough RAM is available so that it would at least be usable by those who have the system resources to assign sufficient RAM.


Maybe a memory leak? So this amount of RAM is only needed during compilation? After that do you run into problems when it is lowered back again?

Excuse my ignorance, but couldn’t we pre-compile during image builds and provide it as a binary? Also as binary updates in Whonix repo?

Possibly. So even if or similar is the issue, it was still worth contacting upstream.


That would break on kernel upgrade (comes from or when using a custom kernel. That’s why DKMS was invented. There are many kernel modules such as wireguard or guest additions. Not sure that’s a leap of faith but if DKMS (kernel module compilation during installation) was easily avoidable, I guess that would be standard practice in Debian.


LKRG is not yet compatible with hardened kernel.

Not worth contacting upstream about it yet. I am still waiting for upstream to provide signed git commits so I can test a newer version before more experimentation is worthwhile.