On Mon, May 11, 2026 at 3:32 PM Andrew Morton <[email protected]> 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?
As of today, livepatch is loaded to the kernel as a module. It requires kernel config CONFIG_LIVEPATCH. If CONFIG_LIVEPATCH is not set in the running kernel, livepatch module won't work. > 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? With CONFIG_LIVEPATCH, and with proper toolchain and keys, this is surely possible. But I guess this comes with some security concerns (sharing the keys, etc.). > 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. > > I *think* this is feasible on distro-based machines? But perhaps not > on stripped-down hyperscalar boxen? Do most distro machines have CONFIG_LIVEPATCH enabled? AFAICT, Ubuntu 26.04 does have it enabled. Thanks, Song
