- LKRG compilation hardening flags, checksec, hardening-check [archive]
- LKRG packagers / downstream wishlist [archive] (signed git commits, signed git tags, version numbers, logo)
- module loading / systemd bug report / suggestion [archive]
- LKRG kills VirtualBox host VMs [archive]
- announcement of this LKRG Debian package on upstream LKRG mailing list [archive]
Nobody in that thread even read past the first few lines…
Very few of the commenters indeed looks like. Following links, let alone reading footnotes, using search engines… Didn’t notice much of that there.
Welcome to reddit
LKRG can cause this:
sudo iptables --list
iptables/1.8.2 Failed to initialize nft: Protocol not supported
That setting seems pointless anyway as the Debian kernel doesn’t even have usermode helpers enabled.
Bug on Qubes, Debian buster.
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)
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
[p_lkrg] ALERT !!! _STEXT MEMORY BLOCK HASH IS DIFFERENT - it is
[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] !!!
[p_lkrg] ALERT !!! SYSTEM HAS BEEN COMPROMISED - DETECTED DIFFERENT 7
Any reference for that? Asking because then I can add that to https://www.whonix.org/wiki/Linux_Kernel_Runtime_Guard_LKRG.
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
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.