VPS 即時核心修補與重新開機有何不同？

VPS 上的即時核心修補功能

即時核心修補會將核心安全修正套用到執行中的機器，不需重新開機，也不會中斷連線。系統會將已修正的函式副本載入為核心模組。每次呼叫舊函式時，系統都會重新導向至新副本，同時伺服器持續處理網路流量。這項機制同時說明了即時修補的適用範圍，以及它無法處理的問題。

它能爭取時間，但無法取代重新開機。已進行 6 個月即時修補的伺服器，磁碟上的舊核心映像仍然是目前開機使用的映像。這些修補也都只存在於記憶體中。

即時核心修補通常會被列為代管方案的功能。在非代管伺服器上，只需執行兩個命令即可自行啟用。這一點值得先了解，再決定是否支付 代管與非代管 VPS 之間的差價。

Live kernel patching 如何運作？

kernel 內建 live patching 核心，並使用 CONFIG_LIVEPATCH 編譯進去。請檢查目前執行中的 kernel 是否包含此功能：

grep CONFIG_LIVEPATCH /boot/config-$(uname -r)

若輸出包含 CONFIG_LIVEPATCH=y，表示目前執行中的 kernel 建置時已包含此核心。若沒有此核心，任何 live patching 服務都無法在該機器上運作。

重新導向本身使用 kernel 的函式追蹤器 ftrace。大多數 kernel 函式在函式最開頭都會編譯一個呼叫指令，位置早於參數或 stack 受到處理之前。ftrace 會使用這個呼叫位置作為 hook。套用 patch 時，live patching 核心會在目標函式註冊 ftrace handler，讓 handler 將執行流程改送至替代函式。kernel 文件的說明很直接：「Livepatching 通常必須在函式進入點的最開頭重新導向程式碼，且此時函式參數或 stack 尚未受到任何修改。」

這句話會帶來兩項後果，之後都很重要。只有 ftrace 能 hook 的函式才可套用 patch，因此未編譯函式進入呼叫的函式完全無法修補。其次，patching 的單位是完整函式，絕不是函式內的單一行。

較困難的部分，是安全地切換正在執行的系統。如果替換函式時，某個 CPU 的 stack 上仍有舊程式碼正在執行，就會混用新舊行為。上游 Linux 以每個 task 的一致性模型處理此問題。kernel 文件將其描述為混合模型：「它結合 kGraft 的每個 task 一致性與 syscall barrier 切換，以及 kpatch 的 stack trace 切換。」只有在 kernel 能確認某個 task 目前不在已修補函式內時，task 才會逐一移至新程式碼。在所有 task 都完成切換前，patch 都處於轉換狀態。

你可以自行查看結果。已套用的 patch 會出現在 /sys/kernel/livepatch 下方。每個 patch 有一個目錄，目錄內會列出已修補的函式。

ls /sys/kernel/livepatch/

若列出的內容為空，表示記憶體中沒有載入 live patch。對於全新的伺服器，這是正常的初始狀態。

即時核心修補無法修正的問題

只有函式本體會套用修補。其他部分不會。

• 變更資料結構。 如果上游修正會在 struct 中新增欄位，或改變現有欄位的意義，就沒有安全的方法可重寫已配置且正在使用的物件。kpatch 專案直接說明了相同情況：「不直接支援修改靜態配置資料的修補。」Shadow variables 與 callbacks 可作為替代方案，但必須針對每個修補手動撰寫，並非自動處理。
• 同時分散在多個函式中的修正。 如果修正需要變更一組函式之間的鎖定順序，就必須同時變更所有函式；一致性模型會切換工作，而不是在單一時間點凍結整台機器。
• 初始化程式碼。 標記為 __init 的函式在伺服器啟動前就已執行並釋放，因此沒有可重新導向的內容。
• 新的核心版本與新功能。 即時修補只能在同一核心系列內移動修補層級。它不會將核心從一個系列升級到下一個系列，也不會新增功能。如果需要較新系列中的功能，例如 Linux 7.1 中加入的變更，就必須安裝該核心並使用它開機。
• 使用者空間。 Canonical 明確說明了界線：「Canonical Livepatch 不會修補 OpenSSL 或 glibc 等使用者空間函式庫，因為這是 unattended-upgrades 或系統管理工具的職責。」即時修補的核心旁邊若仍是過時的 OpenSSL，就不能算是已修補的伺服器。因此，請讓同一台主機上的 unattended upgrades 處理使用者空間套件。

Ubuntu 的服務也有嚴重性界線。Canonical 表示，它「會修補具有 critical 和 high Common Vulnerability Scoring System (CVSS) 與 Ubuntu Priority 評等的核心漏洞。」CVE（common vulnerabilities and exposures）識別碼代表一個漏洞，而 CVSS 是附加到該漏洞的分數。評等為 medium 的核心 CVE 會在磁碟上的套件中修正，但不會套用即時修補。因此，執行中的核心要等到下一次重新開機時才會取得修正，之前不會生效。

即時核心修補有哪些選項？

目前常見的有 3 個系統，它們都使用相同的核心機制。

Canonical Livepatch 透過 Ubuntu Pro 提供。Ubuntu Pro 可供個人免費使用。Canonical 的說法是：「個人使用者在最多 5 台實體機器上，現在及未來都可免費使用」，官方 Ubuntu Community 成員則提高至 50 台。這是截至 2026 年 8 月的文件所載限制。商業用途需要付費訂閱。涵蓋範圍依核心系列與 flavour 授權，包含受支援 long term support (LTS) 版本的 general availability (GA) 核心及其 hardware enablement (HWE) 核心，也涵蓋 generic、aws、azure、gcp、oracle、ibm 和 lowlatency 等 flavour。在依賴此功能前，請先將自己的核心與 Canonical 發布的核心清單比對。

KernelCare 由 TuxCare 提供，是商業代理程式，可支援多個發行版，包括沒有第一方服務的發行版。其文件記載的安裝方式是執行廠商提供的指令碼 curl -s -L https://kernelcare.com/installer | bash，再執行 /usr/bin/kcarectl --register KEY 以使用金鑰型授權。代理程式會依自己的排程檢查新修補程式，而 /usr/bin/kcarectl --update 可強制執行檢查。在重要伺服器上將安裝程式以 pipe 傳給 shell 前，請先閱讀安裝程式內容。

kpatch 和 kGraft 是早期方案。kGraft 源自 SUSE，kpatch 源自 Red Hat。目前 upstream Linux 的即時修補核心，是兩者概念的合併。kpatch 本身正在逐步停止維護：其 README 表示，自 Linux 6.19 起，「kpatch project 已棄用並進入維護模式」，而 upstream kernel 中的 kpatch-build 將由 klp-build 取代。在 RHEL 及其重建版本上，應使用該發行版提供的服務，而不是自行建立修補程式。

請根據發行版支援的功能與授權條款選擇方案。每種方案在核心層級產生的結果都相同。

如何在 Ubuntu 啟用 Canonical Livepatch

先從 Ubuntu Pro 帳戶頁面取得 token。以下兩個命令都需要可用的對外網路連線，因為 client 會連線到 Canonical 的伺服器以完成附加並取得修補程式。

sudo pro attach TOKEN
sudo pro status

不提供 token 直接執行 sudo pro attach 時，會改用瀏覽器流程，並輸出一組代碼，供你在 Canonical 網站輸入。完成附加後，系統會自動啟用建議的服務；在目前的 LTS 版本中，其中包含 Livepatch。如果想自行選擇服務，請使用 sudo pro attach --no-auto-enable。

如果尚未啟用 Livepatch：

sudo pro enable livepatch
sudo canonical-livepatch status

此服務透過 canonical-livepatch snap 執行，因此 snapd 必須正常運作，啟用程序才能完成。pro status 會輸出服務及其授權與狀態的表格。canonical-livepatch status 會輸出每個 kernel 的詳細資訊，而 Canonical 的文件會以以下格式顯示輸出：

last check: 52 seconds ago
kernel: 5.4.0-216.236-generic
server check-in: succeeded
kernel state: ✓ kernel series 5.4 is covered by Livepatch
patch state: ✓ all applicable livepatch kernel modules applied
patch version: 113.1

其中兩行可直接判斷結果。kernel state 顯示目前執行的 series 是否受到服務涵蓋。當你啟動 Livepatch 不支援的 kernel 時，這一行會顯示異常。patch state 顯示適用於該 kernel 的修補程式是否確實已載入。受到涵蓋但沒有套用修補程式，表示 client 發生問題。未受到涵蓋則表示 kernel 發生問題，無法透過 client 設定修正。

如何判斷是否需要重新開機？

Livepatching 消除了緊急性，因此是否需要重新開機不再明顯。您必須主動檢查。

ls -l /var/run/reboot-required
cat /var/run/reboot-required.pkgs

當已安裝的套件需要重新啟動才能生效時，套件管理器會建立 /var/run/reboot-required，而新的 linux-image 套件一定會建立該檔案。.pkgs 檔案會列出提出要求的套件。如果第一個命令回應 No such file or directory，表示自上次開機後沒有任何套件要求重新開機。在目前的 Ubuntu 中，/var/run 是指向 /run 的符號連結，因此使用任一路徑都會存取相同檔案。

此旗標位於 tmpfs 中，每次開機都會重設，因此請對照核心本身確認：

uname -r
dpkg -l 'linux-image-*' | grep ^ii

uname -r 會顯示目前執行中的核心。第二個命令會顯示磁碟上已安裝的核心套件。如果該清單中的 linux-image 比 uname -r 回報的版本新，表示機器仍在執行舊核心，不論 Livepatch 的狀態為何。這項檢查才是關鍵，因為 live patching 的設計目標是讓執行中的核心保持安全，而不是讓它保持最新。

至於同一問題的使用者空間部分，Ubuntu Server 預設會安裝 needrestart。它會列出仍持有已刪除程式庫檔案的執行中服務。

sudo needrestart -r l

-r l 旗標組合表示「僅列出」，因此只會回報，不會變更任何內容。

為什麼重新開機始終無法避免

磁碟上的 kernel 並未變更。Live patches 會載入正在執行的 kernel，但不會寫入 boot image。因此重新開機後，系統會使用 bootloader 選取的 linux-image 啟動，接著 Livepatch client 會重新套用仍適用的 patches。在這兩個時刻之間，系統執行的是未套用 patches 的程式碼。這也是應使用目前版本 kernel，而不是舊版本 kernel 的另一個理由。

Coverage 以 kernel series 為單位，而 series 會停止維護。執行中的 series 不再列於支援清單時，kernel state 行便會停止回報 coverage。唯一的修正方式是改用較新的 kernel。這就需要重新開機。在 LTS release 中，較新的 series 通常會以 hardware enablement kernel 的形式，隨 例如 26.04.1 的 point release 提供。因此替代版本已經位於 archive 中，剩下的只是安排一次啟動。

Medium 和 low severity 的 kernel fixes 絕不會以 live patch 方式套用。它們會留在磁碟上的 package 中，只有在啟動該 kernel 後才會生效。

長時間執行的 kernel 也會累積 patching 無法清理的 state。Canonical 的立場值得引用，因為這是誠實的說法：Livepatch「不是重新開機的替代方案，而是透過防止未排程的重新開機，讓你能更有效控制重新開機時機的工具。」其中承載意義的詞是 未排程。你仍然需要重新開機，但由你選擇時機。

如何排程重新開機並恢復運作

如果無法存取主控台，VPS 重新開機後就可能無法復原。在輸入 reboot 前，先確認機器無法恢復時，仍能重新連入。

• 確認供應商在控制面板提供 serial console 或 VNC（virtual network computing）畫面，並現在就開啟，不要等到服務中斷時才處理。
• 使用 df -h /boot 檢查可用空間。/boot 滿載時，kernel package 在寫入 initramfs（initial RAM filesystem）期間會失敗，可能導致 bootloader 項目指向尚未完成的映像檔。
• 至少保留一個已知可正常運作的舊 kernel。GRUB 會在「Advanced options for Ubuntu」下列出該 kernel。新 kernel 失敗時，啟動舊 kernel 是最快的復原方式。
• 事先找出供應商的 rescue mode。重新開機後如果主控台顯示 initramfs 提示字元，應在該處進行修復。

請在你清醒且能處理問題的時間重新開機：

sudo shutdown -r +5 "Kernel update, back in a moment"

這會將重新開機排程在 5 分鐘後，並向已登入的使用者傳送訊息。sudo shutdown -c 可取消排程。機器恢復後，確認以下兩部分：

uname -r
sudo canonical-livepatch status

uname -r 現在應回報較新的 kernel，而狀態輸出也應回報新的系列已涵蓋。如果機器完全沒有恢復，故障幾乎總是在開機路徑，而不是網路。此時應依照kernel 更新後無法開機的 VPS 指南中的復原方式處理。

為什麼仍需清理舊核心

Live patching 反而會讓這個問題更嚴重，因為即使 linux-image 套件持續安裝，也不再需要重新開機。每個核心都會安裝開機映像、initramfs、模組樹，通常還會安裝 headers 套件。在只有數百 MB 的小型 VPS 上，若另有獨立的 /boot 分割區，安裝三或四個核心就會將其填滿。

/boot 滿載後，下一次核心安裝就會失敗，導致系統無法套用它真正需要的更新。apt autoremove 會在舊核心符合條件後清除它們；但在長期不重新開機的主機上，舊核心不一定已符合條件，因為套件管理程式不會移除你可能仍在使用的核心。

因此，請先確認已安裝的核心，保留目前執行中的核心與一個已知可正常運作的備援核心，再依照 Ubuntu 上安全移除舊核心的程序 移除其餘核心。絕對不要移除 uname -r 目前回報的核心。

FAQ

即時核心修補是否代表 VPS 永遠不需要重新開機？

不代表。即時修補程式會載入正在執行的核心，但不會寫入開機映像，因此磁碟上的 linux-image 仍會維持開機時使用的版本。Canonical 的說法很直接：Livepatch「不是重新開機的替代方案，而是透過避免非預期重新開機，讓您能更有效控制重新開機時機的工具。」當您的核心系列停止維護時，涵蓋範圍也會結束；中等嚴重度的核心修正也完全不會透過即時修補處理。請依您選定的週期安排維護性重新開機，不要等到系統強制要求重新開機。

如何確認即時核心修補確實正在套用修補程式？

執行 sudo canonical-livepatch status，並查看兩行輸出。kernel state 顯示您目前執行的核心系列是否受此服務涵蓋，patch state 顯示該核心的修補程式是否已載入。您也可以使用 ls /sys/kernel/livepatch/ 直接檢查核心端的狀態；此命令會列出每個已載入修補程式所對應的目錄。如果列出內容為空，表示目前沒有任何修補程式套用到記憶體中，無論用戶端回報什麼狀態。

Ubuntu Pro 在個人 VPS 上是否免費？

免費，但有文件所載的使用上限。Canonical 的原文表示，Ubuntu Pro「現在及未來都會對個人用途免費，最多可使用於 5 台實體機器」；截至 August 2026，正式 Ubuntu Community 成員的上限提高至 50 台機器。商業用途需要付費訂閱。您可以從 Ubuntu Pro 帳戶頁面取得 token，使用 sudo pro attach TOKEN 連結機器，再以 sudo pro enable livepatch 啟用服務。

為什麼 Livepatch 執行後，核心 CVE 仍列為未修正？

通常有兩個原因。修正程式可能低於嚴重度門檻，因為 Canonical 的即時修補只處理「具有 critical 和 high Common Vulnerability Scoring System (CVSS) 及 Ubuntu Priority 評等的核心弱點」，其餘問題則交由磁碟上的套件處理。另一種情況是，修正程式無法表達為函式本體的變更；例如上游修改了資料結構，而即時修補無法安全地修改已配置的物件。這兩種情況都以相同方式處理：安裝更新後的核心套件，並開機進入該核心。

即時核心修補完全不涵蓋哪些內容？

使用者空間。Canonical 明確表示，Livepatch「不會修補 OpenSSL 或 glibc 等使用者空間函式庫，因為這是 unattended-upgrades 或系統管理工具的責任。」它也無法提供新的核心版本或新功能，因為它只會替換您目前執行之核心系列中的函式本體。此外，它無法修補 __init 函式，因為伺服器啟動完成時，這些函式通常已經執行完畢並從記憶體釋放。