On Mon, May 11, 2026 at 03:31:58PM -0700, Andrew Morton wrote:
On Mon, 11 May 2026 15:07:51 +0200 Michal Hocko <[email protected]> wrote:
> 2) It's common to run hundreds of different kernel versions across a
> fleet. Since livepatch is kernel-specific, a single CVE suddenly
> requires building and deploying hundreds of individual livepatches—
> far less practical than a simple sysfs write.
LP is certainly a more laborous solution.
<another please-educate-akpm email>
Does a livepatch *have* to be distributed as a ready-to-load kernel
module?
Is it not possible to distribute a "livepatch" to the fleet as a single
string? Send out "make function some_bad_function() return -EINVAL"
and let scripting on each machine figure out how to locally write,
build, sign and install such a livepatch?
That would require that each machine locally contains enough data for
it to be able to build a kernel for the currently-running kernel, and
that each machine contains a build environment.
So we'll need to have a kernel build env, the sources for the current kernel,
debug info, and some sort of a semantic patch (.cocci?) to make the
transformation. I think we could even script all of that per-distro, yes.
I *think* this is feasible on distro-based machines? But perhaps not
on stripped-down hyperscalar boxen?
Few concerns:
1. Tiny/embedded machines that will have a really hard time building a kernel
either because of storage, CPU power, etc... Consider something like your home
router running OpenWRT.
Actually, this is a good example for a killswitch too I think. I went digging
for issues that would affect OpenWRT routers, and
https://www.cve.org/CVERecord?id=CVE-2024-1086 is a good example: OpenWRT
supports user namespaces to allow containers to run on the router, so any
container could then compromise the router.
There's no way to build kernel modules on the router - no toolchain nor storage.
With killswitch, you could simply do something like:
echo "engage nft_verdict_init -1" > /sys/kernel/security/killswitch/control
Which, if I understand the code correctly, would disable us from adding any new
netfilter rules, but existing rules would keep working (and on most routers the
rules are fairly static).
2. Having to install a build env is not only wasteful but also not secure. For
example, a certain hyperscaler we both know does not allow compilers on
production machines. It's probably a good practice for regular distro based
machines too.
3. With secure boot a user can't load their own unsigned modules, so the user
will need to spin their own kernel and enroll their keys. Having to turn off
secure boot is a really bad solution too.
4. Nightmare as far as reproducibility goes: think of all the odd
compiler/toolchain/etc combos you'll encounter. No way to track what went
wrong, where, and how.
--
Thanks,
Sasha
