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

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 https://www.whonix.org/wiki/Linux_Kernel_Runtime_Guard_LKRG 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 https://bugzilla.kernel.org/show_bug.cgi?id=196729 or similar is the issue, it was still worth contacting upstream.


That would break on kernel upgrade (comes from packages.debian.org) 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.


Upstream providing signed git commits now.

LKRG pacakge in Whonix git master and developers repository updated as per:

LKRG version commit 403f2fa92cdb8071a39afa031f08719972aa563e
Date: Thu Jan 16 06:05:15 2020 +0000
Commit message: Fix compilation on non-x86 platforms for kernel 5.3+

Fixed. Reported. And found maybe another (smaller) issue:

? p_kmod_hash+0x2a1/0x3b0 [p_lkrg] - was: LIST HASH IS DIFFERENT -
nf_nat / nf_conntrack Linux version 5.3.0-0


VirtualBox host support is now on the horizon:

1 Like

sysctl vs module parameters / Can sysctl be set before loading the module? | was: bug: LKRG kills VirtualBox host VMs

1 Like

UMH blocked when though lkrg.block_modules = 0


As for LKRG loading it as early as possible is non-trivial. Currently loading LKRG as early as possible would cause some issues. For example it would detect changes by tirdad as malicious and show a lot false positive messages. Asked upstream about it:

Compiling LKRG static into the Kernel / Loading LKRG kernel module as early as possible or after other modules?

1 Like

The wiki page got noticed by spender.

1 Like

Above fixed.


LKRG is compatible with Debian Linux buster-backports 5.4.8-1~bpo10+1 kernel

A Debian issue but unrelated to LKRG:
linux-image-amd64 vs linux-headers-amd64 Debian buster-backports version mismatch bpo.2 vs bpo.3


Related: T950: prevent kernel info leaks

1 Like
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Contributors] [Investors] [Priority Support] [Professional Support]