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

Quote https://www.openwall.com/lkrg/

Linux Kernel Runtime Guard (LKRG) is a loadable kernel module that performs runtime integrity checking of the Linux kernel and detection of security vulnerability exploits against the kernel. As controversial as this concept is, LKRG attempts to post -detect and hopefully promptly respond to unauthorized modifications to the running Linux kernel (integrity checking) or to credentials (such as user IDs) of the running processes (exploit detection). For process credentials, LKRG attempts to detect the exploit and take action before the kernel would grant the process access (such as open a file) based on the unauthorized credentials.

Please check out our presentation slides on LKRG.

While LKRG defeats many pre-existing exploits of Linux kernel vulnerabilities, and will likely defeat many future exploits (including of yet unknown vulnerabilities) that do not specifically attempt to bypass LKRG, it is bypassable by design (albeit sometimes at the expense of more complicated and/or less reliable exploits). Thus, it can be said that LKRG provides security through diversity , much like running an uncommon OS kernel would, yet without the usability drawbacks of actually running an uncommon OS. As free LKRG becomes somewhat popular and maybe a target of some exploits, we might introduce paid LKRG Pro as a means to fund the project and provide further diversity (with Pro’s smaller userbase being beneficial), extra and specialized functionality (e.g., detection of container escapes), and maybe distro-specific binary builds.

CONFidence 2018: Linux Kernel Runtime Guard (LKRG) under the hood (Adam “pi3” Zabrocki)


A related Qubes bug, but not a blocker since we can use Qubes VM kernel (i.e. kernel from inside VM and not from dom0):


I am considering to package LKRG for Debian buster, Whonix, Kicksecure and Qubes Debian templates.

(Inside Qubes OS. Using Qubes VM kernel, i.e. kernel by Debian. See related.)

Initially it will be an opt-in package to encourage wider testing. Should that work well, installation of LKRG by default will be considered.

Current status: I’ve successfully compiled and load the LKRG module in a Qubes Debian standalone VM using Qubes VM kernel.



LKRG doesn’t seem to be that well known which means less people are reviewing the code so there may be a bunch of vulnerabilities. This is worse as it’s a kernel module which would add a lot of attack surface.

It also doesn’t seem to be very mature yet

LKRG is currently in an early experimental stage. We expect occasional false positives (integrity violations and/or exploits detected when there aren’t ones). LKRG’s current response to kernel integrity violations is merely reporting those in kernel messages (which obviously doesn’t mitigate attacks when those are for real) and its current response to unauthorized process credentials is killing the process (which does defeat many exploits, but is a rather mild response nevertheless). This will likely change as LKRG becomes more mature.

This does seem like a good idea though. There’s a lot more info on the wiki https://openwall.info/wiki/p_lkrg/Main


Will be further researcherd.

I’ve read somewhere, that off-the-shelf malware disables itself when LKRG is detected.

Saw the presentation video yet? LKRH is said to disable whole classes of exploits. Requiring a full read/write exploit possibly specifically written to circumvent LKRG.

Also have to research its authors more. openwall / solar designer has an excellent professional track record. I know him a bit from professional experience. He’s of high morals. Yet have to learn more who authored / reviewed LKRG.

A project worth supporting even if turns out not ready for default installation. Can’t say yet. Still learning.


Started describing LKRG:

1 Like
1 Like


got reply:


Probably due to #5456 / #2844. This might be fixed after upgrades.

1 Like

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@…ts.debian.org) (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 https://www.whonix.org/wiki/Linux_Kernel_Runtime_Guard_LKRG.

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