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@opensuse.org To contact the owner, e-mail: ulp-devel+owner@opensuse.org