Kernel live patching
Server > Kernel live patching (/server/livepatch, Super Administrator
only) shows whether this server's kernel can take security fixes without a
reboot, which fixes are loaded, and whether a kernel update is installed but
not running.
A live patch is code that is loaded into the running kernel. HiTechCloud does not build patches and does not sell a patch service. What it does is read the kernel's own state, switch on the live-patch mechanism the distribution provides, and take any loaded patch back out.
Where patches come from
| Distribution | Patch source | What the page offers |
|---|---|---|
| Red Hat Enterprise Linux | Red Hat's kpatch-patch packages (a Red Hat subscription is needed; selected Important and Critical CVEs only, for a limited time after each kernel update) | Turn on, apply, turn off |
| Ubuntu | Canonical Livepatch, through Ubuntu Pro. Attach the server to Ubuntu Pro yourself (pro attach); HiTechCloud never handles the token | Turn on, apply, turn off, once Pro is attached |
| AlmaLinux, Rocky Linux, Debian and others | None that the distribution publishes | Status only. Install kernel updates and reboot |
If KernelCare or Ksplice is installed, the page changes nothing: two live-patch systems must not patch one kernel.
A live patch does not replace a reboot. Some fixes cannot be live-patched at all, and Red Hat and Canonical publish patches for some kernels and some CVEs only. Loading any live patch marks the kernel as modified, which a vendor's support may take into account.
What the page shows
- the running kernel, its build ID, whether it was built with live patching
and exposes
/sys/kernel/livepatch, Secure Boot, kernel lockdown, and whether the kernel enforces module signatures - the patches that are loaded, with their state, and the CVEs they name
- a banner when a newer kernel is installed than the one that runs
Roll back reverts a loaded patch and removes it. It waits up to a minute for the kernel to finish switching. If a task is still inside a patched function it stops and says so; it never forces the switch, and a reboot is then the way out. Every action asks for confirmation, runs in the background and is written to the activity log.
The daily check
hitechcloud-livepatch.timer runs once a day. When a kernel newer than the
running one is installed it raises one notification for the administrators
(event kernel.reboot_required, so channels can filter on it). It says
whether a live patch is active, and repeats only when a still newer kernel
arrives.
Patches from the owner's mirror
The owner of the HiTechCloud installation can build, review, sign and publish live patches of their own (see Building and signing live patches). Nothing of that exists until the owner sets it up: no patch key is trusted and no mirror address is set, so a server fetches nothing and accepts nothing.
When the owner has set a mirror, the page shows its state: whether an address is set, whether a key is trusted, when the signed index was last fetched and until when it is valid, and the patches the index lists for exactly this kernel build, with the CVEs they fix. Check the mirror asks for the index. Apply from the mirror downloads one patch and loads it, after a confirmation. Both are for the Super Administrator only, and carry no path, URL or file: the page can only pick one of the patches the signed index lists, and the mirror's address is set on the command line, never on the page.
What is checked before anything reaches the kernel, in this order:
- the index is signed by a key this server trusts, is not expired and is not older than the last index seen here
- the patch is for this kernel release, build ID and architecture, and the owner has not withdrawn it
- each downloaded file has the size and SHA-256 the index names
- the manifest is signed by a trusted key, names the module's SHA-256, and has not expired; its serial is not lower than the last patch applied here
- the bundle carries a complete, signed-off human review of every CVE it claims, bound to this module and kernel build
- a kernel that enforces module signatures (Secure Boot, lockdown) gets a module that carries a kernel module signature
- the module is a live patch for this kernel release, and the kernel switches to it within a minute, or it is taken out again
The release signing key is never accepted as a live-patch key. A patch loaded this way is not kept across a reboot. If the owner withdraws a patch that is loaded, the page says so and Roll back removes it.
Patches from a directory
The command line can load a signed patch bundle from a directory. The page
cannot: it has no field that takes a file or a path. The same checks apply as
for the mirror. No key is trusted by default, so none is accepted until the
server's owner adds one to /etc/hitechcloud/livepatch/trusted-keys. A patch
loaded this way is not kept across a reboot.
hitechcloudcli server-livepatch status [--json]
hitechcloudcli server-livepatch enable --yes
hitechcloudcli server-livepatch disable --yes
hitechcloudcli server-livepatch apply --yes
hitechcloudcli server-livepatch apply --bundle <dir> --yes
hitechcloudcli server-livepatch rollback <patch> --yes
hitechcloudcli server-livepatch mirror [status|refresh|set <address>|clear] [--json]
hitechcloudcli server-livepatch fetch <patch> --yes
hitechcloudcli server-livepatch watch [--quiet|enable|disable]