Hello,
I've been asked to share information on the architecture of kernel live
patching userspace infrastructure so that it can serve as a model for the
ULP implementation. The description is intentionally high-level for the
sake of keeping the text short. More technical details can be provided in
areas of your interest.
The main areas covered below are
1) Building patches in Build Service
2) Binding patches to the respective RPM packages
3) Patching upon package installation
4) KLP tool
Building patches in Build Service
---------------------------------
To state the obvious, live patching patches *old* packages. I.e. a fix for
the kernel goes out both as a live patch RPM and the rebuilt kernel RPM.
Kernel live patches bind deeply into kernel code, so we do build the live
patch against the previously released kernel package. However, Build
Service keeps only the latest RPM for build and throws away old packages.
For that reason, live patches are built against so-called "maintenance
projects" which hold the historical sources and binary RPMs.
Binding patches to the respective RPM packages
----------------------------------------------
Now that we have a kernel module, we've got to tell the packaging system to
install it only for the corresponding kernel. Mind that there may be
multiple kernel packages installed on the system and one of the kernels is
running. The binding used to be done via version+release numbers but that
required some special tweaks in Build Service. Recently, we've changed that
to (GIT) source hash binding, assuming that all binaries generated from the
same sources will be equal[1]. The kernel package provides
"kernel-<flavor>-srchash-<hash>" symbol and the live patch requires the
same. The benefit is that the source hash is known at package submission
time. In addition, there is RPM "Supplements:
packageand(kernel-<flavor>-srchash-<hash>:kernel-livepatch-tools)", which
is a zypper specific way to pull the live patch into the system when both
the kernel package and kernel-livepatch-tools are being installed.
Patching upon package installation
----------------------------------
RPM post-install script triggers `rpm-helper` that tries to load the live
patch into the running kernel if applicable. Then it refreshes initrd to
include the live patch so that it can be loaded upon (unplanned?) reboot.
`rpm-helper` script is packaged in kernel-livepatch-tools.
KLP tool
--------
There is a system inspection tool called `klp`. The tool allows the user to
check what patches are loaded into the kernel, which vulnerabilities are
fixed by the patch and what is the system status. In the past, it also
performed some maintenance tasks, which, however, are no longer necessary
thanks to the improved kernel infrastructure.
I hope that the above information provides insight into the inner workings
of the kernel live patching and can serve as a starting point for the ULP
implementation.
Libor
[1] Yes, I know this assumption broke many times in the past but we are
still surviving.
--
Libor Pechacek
SUSE Labs Remember to have fun...
--
To unsubscribe, e-mail: ulp-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: ulp-devel+owner(a)opensuse.org
