Live patching Linux jadra: Sprievodca 20…

Q: Funguje kpatch na Rocky Linuxe a AlmaLinuxe?

Základný kpatch nástroj áno, no Rocky a Alma nemajú prístup k Red Hat kpatch RPM repozitárom, takže hotové patch moduly nie sú dostupné. Buď treba stavať vlastné cez kpatch-build , alebo pragmaticky použiť TuxCare KernelCare, ktorý má natívnu podporu pre oba klony.

Aktualizované: 3. augusta 2026

Live patching linuxového jadra je technika, ktorá umožňuje aplikovať opravy kritických CVE do bežiaceho jadra bez rebootu servera pomocou ftrace trampolín, ktoré presmerujú volania zraniteľných funkcií na opravené verzie priamo v pamäti. V roku 2026 sa live patching stal štandardnou požiadavkou pre SOC 2, PCI-DSS a FedRAMP audit. Hlavné riešenia sú kpatch od Red Hatu, Canonical Livepatch pre Ubuntu a TuxCare KernelCare, ktorý pokrýva mixované distribúcie. Tento článok ich porovnám a ukážem, ako ich zapojiť do CI/CD pipeline.

Live patching aplikuje CVE opravy do bežiaceho jadra cez ftrace trampolíny bez rebootu, ale nedokáže patchovať zmeny v layoute dátových štruktúr (napr. struct task_struct); vtedy je reboot nevyhnutný.
kpatch je natívne riešenie pre RHEL 10, Rocky a AlmaLinux, distribuované cez kpatch-dnf. Pokrýva však len okolo 10 % kernelových CVE a chýba mu podpora arm64.
Ubuntu Livepatch vyžaduje Ubuntu Pro subscription (zdarma pre 5 osobných strojov), beží ako canonical-livepatch démon a podporuje LTS jadrá s 13-mesačným oknom.
TuxCare KernelCare pokrýva multi-distro fleety vrátane arm64 a rozširuje patching aj do userspace cez LibCare za približne 50 USD/server/rok.
Automatizácia live patchingu v CI/CD pipeline dramaticky skracuje MTTR pre kernelové CVE z týždňov na hodiny. Kľúčom je metrika pokrytia patch inventára, nie počet aplikovaných patchov.
Live patching nenahrádza reboot úplne. Kumulatívne obmedzenia si vynútia reboot každých 6 až 12 mesiacov, takže naďalej potrebuješ maintenance windows a orchestráciu.

Čo je live patching linuxového jadra?

Live patching (alebo rebootless patching) je mechanizmus, ktorý dovoľuje aplikovať bezpečnostné opravy priamo do bežiaceho jadra bez toho, aby sa musel systém reštartovať. V klasickom workflowe znamenala kritická kernelová zraniteľnosť buď okamžitý reboot fleetu (a s ním výpadok služby), alebo týždne až mesiace expozície, kým sa čakalo na maintenance window. Live patching túto voľbu odstraňuje: CVE fix sa dá vydať a nasadiť do produkcie počas otvorenej pracovnej doby, bez plánovanej odstávky.

Základ tvorí kernelový subsystém livepatch, ktorý bol zlúčený v jadre 4.0 a odvtedy sa stal chrbticou pre všetky komerčné aj open-source riešenia. Podporuje ho x86-64, ppc64le, s390x a od jadra 5.10 aj arm64 (aj keď vendor coverage tu ešte pokuľháva). V praxi to znamená, že môžeš mať bežiaci webserver s uptime 400+ dní a stále mať nakumulované všetky kritické CVE opravy. Presne to hardening framework CIS Benchmark aj STIG v poslednej revízii požaduje.

Ako som opisoval v článku spevnenie linuxového jadra cez sysctl, patching je len jedna vrstva obrany. Live patching sa nevymyká, len ju dopĺňa.

Ako live patching jadra funguje pod kapotou?

Technicky live patching stojí na dvoch kernelových mechanizmoch: ftrace (function tracer) a livepatch subsystem. Keď sa aplikuje patch, kernel modul obsahujúci opravenú verziu funkcie sa načíta cez insmod a livepatch API v ňom zaregistruje trampolíny. Ftrace má už predregistrované hooky v každej funkcii kernelu (kompilovanej s -pg), takže volanie zraniteľnej funkcie sa dá v runtime presmerovať na opravenú verziu.

Kľúčové je, že sa nemení pôvodný kód, len sa pridá skok. To dáva live patchingu dve dôležité vlastnosti. Prvá, je bezpečný proti čiastočnej aplikácii (buď je patch aktívny, alebo nie je). Druhá, nedokáže patchovať dátové štruktúry. Ak CVE fix vyžaduje pridať nové pole do struct sock, žiadny live patch to nezvládne, pretože všetky existujúce inštancie štruktúry majú starý layout a nový kód by čítal mimo alokovanú pamäť. Vtedy sa aj tak treba pripraviť na reboot.

Proces aplikácie vyzerá zhruba takto:

# Zjednodušená sekvencia toho, čo sa deje pri kpatch load
insmod /var/lib/kpatch/<kernel>/kpatch-CVE-2026-XXXX.ko
# 1. Modul zavolá klp_register_patch()
# 2. Livepatch API vytvorí zoznam funkcií na presmerovanie
# 3. Pre každú funkciu sa cez ftrace nastaví handler
# 4. Prechodová konzistencia: čaká sa, kým žiadny task
#    nie je uprostred vykonávania starej verzie funkcie
# 5. Patch sa označí ako "enabled" v /sys/kernel/livepatch/

Konzistenčný model (nazýva sa hybrid consistency model) je najzaujímavejšia časť. Kernel čaká, kým každý task nechá starú verziu funkcie za sebou; u dlho bežiacich threadov to môže trvať sekundy. V oficiálnej dokumentácii kernel.org o livepatch subsystéme nájdeš detailný popis prechodového algoritmu, ktorý je základom pre všetky vendor riešenia nižšie.

kpatch na RHEL 10, Rocky Linuxe a AlmaLinuxe

kpatch je natívne riešenie od Red Hatu a v roku 2026 je štandardom pre RHEL 10, Rocky Linux 10 a AlmaLinux 10. Distribuuje sa cez kpatch-dnf plugin, ktorý automaticky sťahuje patch moduly pre bežiace jadro z base RHEL repozitárov. Prakticky to znamená, že namiesto samostatnej správy máš patching integrovaný priamo do bežného dnf workflowu.

Inštalácia a prvá aplikácia na RHEL 10:

# 1. Overiť subscription (kpatch vyžaduje aktívny RHEL entitlement)
sudo subscription-manager status

# 2. Nainštalovať kpatch DNF plugin
sudo dnf install -y kpatch-dnf

# 3. Zapnúť automatické stiahnutie patchov pre aktuálne aj budúce jadrá
sudo dnf kpatch auto

# 4. Aplikovať konkrétny patch pre bežiace jadro
sudo dnf install -y "kpatch-patch-$(uname -r | sed 's/\.x86_64$//')"

# 5. Overiť, že patch beží
sudo kpatch list
# Loaded patch modules:
# kpatch_CVE_2026_1234 [enabled]
#
# Installed patch modules:
# kpatch_CVE_2026_1234 (5.14.0-503.el10.x86_64)

# 6. Skontrolovať livepatch subsystém
ls /sys/kernel/livepatch/
cat /sys/kernel/livepatch/kpatch_CVE_2026_1234/enabled

Na klonoch (Rocky, AlmaLinux) je situácia zložitejšia. Nemajú prístup k Red Hat kpatch RPM repozitárom a Rocky Linux Foundation vyvíja vlastnú alternatívu rocky-kpatch, ktorá je zatiaľ v experimentálnej fáze. V produkcii pre Rocky/Alma pragmaticky odporúčam TuxCare KernelCare (viď nižšie), pretože kpatch coverage je tam obmedzená len na CVE, pre ktoré si niekto sám postavil patch modul.

Kritická výhrada, ktorú v internom Slack channeli našej DevSecOps skupiny opakujem stále dokola: kpatch nepokryje 100 % CVE. Realistický pomer je okolo 10 % z celkového počtu vydaných kernelových fixov ročne. Red Hat vydáva live patch len pre kritické a niektoré high-severity CVE, ktoré sú operatívne aplikovateľné cez ftrace. Zvyšok si aj tak vynúti reboot počas maintenance windowu.

# CI-ready kontrola kpatch stavu (Bash + jq)
#!/usr/bin/env bash
set -euo pipefail

STATUS_JSON="/tmp/kpatch-status.json"
LOADED=$(kpatch list | awk '/Loaded/,/^$/' | grep -c 'enabled' || echo 0)
INSTALLED=$(kpatch list | awk '/Installed/,/^$/' | grep -c 'kpatch' || echo 0)

jq -n \
  --arg kernel "$(uname -r)" \
  --argjson loaded "$LOADED" \
  --argjson installed "$INSTALLED" \
  '{kernel: $kernel, loaded_patches: $loaded, installed_patches: $installed}' \
  > "$STATUS_JSON"

# Fail pipeline, ak inštalované patche nie sú aj loadnuté
if [[ "$LOADED" -ne "$INSTALLED" ]]; then
  echo "::error::kpatch drift detected: $LOADED loaded vs $INSTALLED installed"
  exit 1
fi

Ubuntu Livepatch a Canonical Livepatch démon

Canonical má vlastnú implementáciu (Ubuntu Livepatch), ktorá beží ako systemd služba canonical-livepatch a sťahuje patch moduly z Canonical Livepatch Service. Aktuálne v roku 2026 vyžaduje Ubuntu Pro subscription, ktorá je zdarma pre osobné použitie (do 5 strojov) a platená pre komerčné nasadenia. Podporuje LTS jadrá 20.04, 22.04, 24.04 a 26.04, každé so sliding 13-mesačným oknom.

Zapnutie Livepatchu na Ubuntu 24.04 LTS:

# 1. Zaregistrovať stroj v Ubuntu Pro
sudo pro attach <token>

# 2. Zapnúť livepatch službu
sudo pro enable livepatch

# 3. Overiť stav
sudo canonical-livepatch status --verbose
# last check: 3 minutes ago
# kernel: 6.8.0-45-generic
# livepatch:
#   status: applied
#   version: "88.1"
#   fixes:
#     - name: CVE-2026-XXXX
#       patched: true

# 4. Manuálne vynútiť refresh (užitočné po CVE announcementoch)
sudo canonical-livepatch refresh

Ubuntu Livepatch je operatívne najjednoduchší, pretože má autonómneho démona, ktorý si sám sťahuje aj aplikuje patche a nevyžaduje žiadny orchestrator. To je zároveň jeho slabina: v CI/CD prostredí, kde chceš mať auditovateľný patch inventár a explicitnú kontrolu nad čím a kedy, autonomous update model komplikuje compliance reporting. Honestly, v praxi ho párujem s Wazuh alebo osquery ako externým inventarizátorom bežiacich patchov, inak sa auditorské otázky množia.

Rovnako ako pri kpatchu, coverage v Ubuntu Livepatchi je selektívna. Canonical explicitne dokumentuje, že patchuje "high a critical CVE", čo v praxi znamená približne 5 až 10 % z celkového toku Ubuntu security updates. Ostatné bezpečnostné opravy sa aplikujú cez klasický unattended-upgrades a v niektorom bode vyžadujú reboot.

TuxCare KernelCare pre multi-distro fleet

TuxCare KernelCare je komerčné riešenie od CloudLinux, ktoré pokrýva prakticky každú major distribúciu vrátane RHEL, Rocky, Alma, Ubuntu, Debianu, SUSE, Oracle Linuxu a Amazon Linuxu. Cena okolo 50 USD/server/rok robí z KernelCare atraktívnu voľbu pre mixované prostredia, kde by sa inak muselo platiť samostatný subscription pre RHEL aj Ubuntu Pro.

Kľúčové odlišnosti oproti vendor riešeniam:

Coverage: KernelCare tvrdí pokrytie až 100 % kernelových CVE, pretože stavia patch moduly interne a nespolieha sa na upstream vendor coverage decisions.
Arm64: Podpora arm64 je natívna. Dôležité pre AWS Graviton a Ampere Altra hostingy, kde kpatch nemá coverage.
LibCare: Rozšírenie, ktoré patchuje aj shared libraries (glibc, OpenSSL) v bežiacich procesoch, čím obchádza potrebu reštartovať dlho bežiace démony.
ePortal: On-prem varianta patch servera pre air-gapped prostredia. Kritické pre finančné a govtech deployments.

Inštalácia na Rocky Linux 10:

# 1. Registrácia
curl -s -L https://kernelcare.com/installer | sudo bash

# 2. Aktivácia licencie
sudo kcarectl --register <KEY>

# 3. Prvá aplikácia dostupných patchov
sudo kcarectl --update

# 4. Overenie stavu
sudo kcarectl --info
sudo kcarectl --patch-info
# Patch level: 128
# CVE-2026-XXXX: applied
# CVE-2026-YYYY: applied
# ...

# 5. Zapnúť automatické stiahnutie/aplikáciu
sudo systemctl enable --now kcare-tunefsd

V praxi som KernelCare nasadzoval na fleet 200+ VM zmiešaný Rocky/Ubuntu a najväčšia výhra bola konzistentnosť patch levelov naprieč distribúciami. Namiesto dvoch samostatných dashboardov (kpatch + livepatch) máš jeden. A hlásenie do compliance systému je oveľa čistejšie, čo mi ušetrilo asi tri týždne prípravy na SOC 2 audit v Q1.

Porovnanie: kpatch vs Ubuntu Livepatch vs KernelCare

Na výber medzi troma vendormi najviac vplýva mix distribúcií vo tvojom fleete, architektúra (x86-64 vs arm64) a to, či je akceptovateľná selektívna CVE coverage. Táto tabuľka zhrnie kľúčové dimenzie:

Kritérium	kpatch (Red Hat)	Ubuntu Livepatch	TuxCare KernelCare
Podporované distribúcie	RHEL 8/9/10, CentOS Stream	Ubuntu LTS 20.04 až 26.04	15+ distribúcií vrátane Rocky, Alma, Debian
Pokrytie CVE	~10 % (kritické + niektoré high)	~5 až 10 % (high + critical)	Deklaratívne až 100 %
Architektúry	x86-64, ppc64le	x86-64, arm64 (LTS jadrá)	x86-64, arm64
Cena / rok / server	V rámci RHEL subscription (~1300 USD)	Ubuntu Pro (zdarma osobne, ~225 USD komerčne)	~50 USD (multi-distro)
Userspace patching	Nie	Nie	Áno cez LibCare (glibc, OpenSSL)
Air-gapped support	Cez Satellite	Cez on-prem Landscape	Cez ePortal
Automatizácia	Manuálna, DNF orchestrácia	Autonómny démon	Autonómny + CI/CD friendly CLI

Praktická rada zo skúseností: ak máš jednu distribúciu a už platíš vendor subscription, drž sa natívneho riešenia, ktoré ti operatívne najlepšie zapadne. Multi-distro fleety takmer vždy končia pri KernelCare, pretože per-distro subscription matematika sa rýchlo prevráti v jeho prospech.

Automatizácia live patchingu v CI/CD pipeline

Toto je časť, ktorá ma baví najviac. Pointa nie je "spustiť dnf update v cron jobe". Pointa je urobiť live patching súčasťou tej istej pipeline, ktorá už deploy-uje aplikačný kód, s rovnakými auditovacími zárukami, canary rollout a rollback stratégiou. Podobný prístup som opísal aj pri spevnení systemd služieb a princíp je rovnaký: čokoľvek, čo dokáže povaliť produkciu, patrí za CI gate.

Základná anatómia GitLab CI pipeline pre kernel live patching (rovnaký vzor funguje aj v GitHub Actions):

# .gitlab-ci.yml
stages:
  - inventory
  - canary
  - rollout
  - verify

variables:
  ANSIBLE_INVENTORY: "inventory/production.yml"
  KERNEL_PATCH_LEVEL: "128"

collect-current-state:
  stage: inventory
  image: registry.internal/ansible:2.16
  script:
    - ansible all -i $ANSIBLE_INVENTORY -m shell
      -a "kcarectl --info --json || kpatch list --json || canonical-livepatch status --format=yaml"
      > artifacts/patch-baseline.json
    - python3 tools/patch-drift-check.py artifacts/patch-baseline.json
  artifacts:
    paths: [artifacts/]

apply-canary:
  stage: canary
  script:
    - ansible canary_hosts -i $ANSIBLE_INVENTORY -m shell
      -a "kcarectl --update --level=$KERNEL_PATCH_LEVEL"
    - sleep 300  # 5 min baking na canary
    - ./tools/smoke-tests.sh canary_hosts
  when: manual
  only: [main]

rollout-fleet:
  stage: rollout
  script:
    - ansible-playbook -i $ANSIBLE_INVENTORY playbooks/kernelcare-apply.yml
      --extra-vars "target_level=$KERNEL_PATCH_LEVEL"
      --forks 20 --serial "10%"
  when: on_success
  needs: [apply-canary]

verify-coverage:
  stage: verify
  script:
    - python3 tools/verify-cve-coverage.py
      --required "CVE-2026-XXXX,CVE-2026-YYYY"
      --inventory $ANSIBLE_INVENTORY

Kľúčové vlastnosti, ktoré tento pipeline dostávajú do produkčného stavu:

Canary stage s manual gate: patch sa nasadí najprv na 5 % fleetu s 5-minútovým baking oknom, potom sa čaká na explicitný ľudský súhlas. Toto som pochopil až po jednom škaredom incidente, kde automated fleet-wide push kernelového patchu (aj live) odhalil interakciu s naším vlastným kmod modulom, ktorú upstream vendor netestoval.
Serial rollout 10 %: Ansible rolluje v batchoch, takže katastrofa sa dá zastaviť v priebehu sekúnd.
Verifikácia CVE coverage: pipeline explicitne overí, že požadované CVE ID sú aplikované na každom hoste. Toto je metrika, ktorú compliance auditor chce vidieť, nie počet loadnutých patch modulov.

Skener ako Trivy alebo Grype v tejto pipeline ignorujem, pretože ich kernel CVE reporting je pre live-patched systémy nespoľahlivý. Stále číta uname -r a nevie o applied patchoch. Presnejšia signalizácia príde z toho, čo hovorí samotný livepatch subsystém. Ušetril som si tým veľa času, ktorý by inak išiel na tikety typu "prečo Trivy stále hlási CVE-2026-XXXX, keď je patchnuté".

Limitácie live patchingu, ktoré nesmieš ignorovať

Live patching nie je strieborná guľka. Má technické limity, ktoré určujú, kde môže a kde nesmie nahradiť reboot. Prvý limit už bol spomenutý: zmeny v layoute dátových štruktúr nie sú patchnuteľné. Ak CVE fix pridá pole do struct file alebo mení veľkosť struct socket, live patch to nezvládne a distribútor jednoducho vydá kernel update s reboot requirementom.

Druhý limit sú funkcie s dlhými prechodovými stavmi. Livepatch čaká, kým každý task opustí zraniteľnú funkciu. Ak však beží proces zaseknutý v D stave alebo v dlhej syscall waitu, prechod môže "zamrznúť" a patch sa nikdy nedokončí. V produkcii sa to prejaví ako patch, ktorý je "installed", ale nikdy "enabled". Dlhé D-state procesy treba killovať alebo servery restartovať.

Tretí a najviac ignorovaný limit sú kumulatívne obmedzenia. Každý live patch pridáva overhead, konflikty medzi patchmi sa akumulujú a distribútori vydávajú tzv. "cumulative patchsets", ktoré po istom čase (typicky 6 až 12 mesiacov) vyžadujú reboot pre aplikáciu nového base setu. V praxi to znamená, že aj s live patchingom je maintenance window každý polrok stále realitou.

# CI-friendly gate proti stromu kumulatívnych obmedzení
# Zabezpečí, že sa nezabudne na reboot vyžadovaný po X mesiacoch
#!/usr/bin/env bash
set -euo pipefail

MAX_UPTIME_DAYS=180
UPTIME_DAYS=$(awk '{print int($1/86400)}' /proc/uptime)

if [[ "$UPTIME_DAYS" -gt "$MAX_UPTIME_DAYS" ]]; then
  echo "::warning::Host $(hostname) beží ${UPTIME_DAYS} dní, plánuj reboot pre reset patch base"
  # Odoslať do PagerDuty/Slack ako maintenance ticket
  curl -X POST "$SLACK_WEBHOOK" \
    -d "{\"text\":\"Reboot needed: $(hostname) uptime ${UPTIME_DAYS}d\"}"
fi

Compliance: live patching, PCI-DSS, SOC 2 a CIS

Compliance frameworky v roku 2026 už explicitne uznávajú live patching ako validný mechanizmus pre CVE remediation. PCI-DSS 4.0.1 v requirement 6.3.3 hovorí o "critical vulnerabilities patched within one month", pričom live patching je akceptovateľný spôsob splnenia. Auditor však chce vidieť dôkaz, že patch je skutočne enabled, nie len installed. Túto rozdielnosť som na prvom audite úplne prehliadol a stálo ma to dva dni doťahovania evidencie.

SOC 2 CC7.1 (change management) požaduje auditovateľnú trail patchovacích operácií, a tu narazia autonomous daemony ako Ubuntu Livepatch, kde patch push je iniciovaný vendorom, nie interným change ticketom. Riešenie je párovanie s CMDB alebo automatizovaným auditom cez OpenSCAP, ktorý zaznamenáva stav pred a po každej zmene. Pomôže aj externá referencia: oficiálny PCI Security Standards dokument uvádza konkrétne evidence patterny, ktoré akceptujú QSA firmy.

CIS Benchmark pre RHEL 10 (level 2, 2026 revízia) v sekcii 1.3 priamo referuje live patching ako odporúčaný mechanizmus pre "Ensure kernel patches are applied within SLA". Pri CIS auditoch je najčastejšia otázka, ktorú od nás pri OpenSCAP scanoch dostávame: "prečo rpm -q kernel ukazuje starý build?". Odpoveď je jednoduchá: live patching nemení nainštalovaný kernel package, mení len bežiaci obraz v pamäti.

Často kladené otázky

Je live patching bezpečný pre produkčné servery?

Áno, ale s dvomi podmienkami: canary rollout na malej vzorke fleetu pred plným nasadením a monitoring pomocou /sys/kernel/livepatch/<patch>/enabled, aby sa zachytil zaseknutý prechodový stav. V praxi je live patching bezpečnejší než reboot, pretože nespôsobí výpadok služby ani stratu warm caches.

Dokáže live patching linuxového jadra reboot úplne odstrániť?

Nie. Live patching odstraňuje reboot pre selektívne kritické CVE, no zmeny v layoute dátových štruktúr, major kernel version upgrades a kumulatívne obmedzenia (typicky každých 6 až 12 mesiacov) reboot stále vyžadujú. Maintenance windows sú tak menej časté, nie eliminované.

Je Ubuntu Livepatch zdarma?

Áno, Ubuntu Livepatch je zdarma cez Ubuntu Pro pre osobné použitie do 5 strojov a pre malé open-source projekty. Komerčné nasadenie vyžaduje platený Ubuntu Pro subscription (približne 225 USD/server/rok), ktorý okrem Livepatchu obsahuje aj ESM a Landscape management.

Funguje kpatch na Rocky Linuxe a AlmaLinuxe?

Základný kpatch nástroj áno, no Rocky a Alma nemajú prístup k Red Hat kpatch RPM repozitárom, takže hotové patch moduly nie sú dostupné. Buď treba stavať vlastné cez kpatch-build, alebo pragmaticky použiť TuxCare KernelCare, ktorý má natívnu podporu pre oba klony.

Aké typy kernelových CVE nedokáže live patching opraviť?

Live patching nepokrýva CVE, ktoré vyžadujú zmenu layoutu dátových štruktúr, novú konfiguráciu boot parametrov, aktualizáciu firmvéru/mikrokódu procesora alebo zmenu v initramfs. Rovnako sa netýka CVE v userspace komponentoch (glibc, systemd), pokiaľ nepoužívaš LibCare rozšírenie od TuxCare.