Live kernel patching hay reboot VPS: khác gì?

Live kernel patching làm gì trên VPS

Live kernel patching áp dụng các bản sửa lỗi bảo mật của kernel cho máy đang chạy mà không cần reboot và không làm mất kết nối. Một bản sao đã sửa của một hàm được nạp dưới dạng kernel module. Mọi lời gọi đến hàm cũ được chuyển hướng đến bản sao mới trong khi máy chủ vẫn tiếp tục xử lý network traffic. Cơ chế này giải thích cả những việc live patching làm tốt và những việc nó không thể làm.

Live patching giúp có thêm thời gian. Nó không loại bỏ yêu cầu reboot. Server đã được live patching trong sáu tháng vẫn khởi động bằng kernel image cũ trên disk. Tất cả các bản patch đó chỉ tồn tại trong memory.

Live patching thường được quảng bá như một tính năng của managed plan. Trên một máy chủ unmanaged, bạn có thể tự bật tính năng này bằng hai lệnh. Bạn nên biết điều đó trước khi trả thêm tiền cho khác biệt giữa VPS managed và unmanaged.

Live kernel patching hoạt động như thế nào?

Kernel có sẵn một lõi live patching, được biên dịch cùng với CONFIG_LIVEPATCH. Kiểm tra kernel đang chạy:

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

Nếu có dòng CONFIG_LIVEPATCH=y, kernel đang chạy được build với lõi này. Nếu không có lõi, không live patching service nào có thể hoạt động trên máy đó.

Cơ chế chuyển hướng sử dụng ftrace, function tracer của kernel. Hầu hết function của kernel được biên dịch với một lệnh gọi ngay đầu function, trước khi các tham số hoặc stack bị thay đổi. Ftrace dùng vị trí lệnh gọi đó làm hook. Khi áp dụng patch, live patching core đăng ký một ftrace handler cho function đích. Handler sẽ chuyển việc thực thi sang function thay thế. Tài liệu kernel mô tả rõ: "Livepatching typically needs to redirect the code at the very beginning of the function entry before the function parameters or the stack are in any way modified."

Có 2 hệ quả từ điều này và cả hai đều quan trọng về sau. Chỉ function mà ftrace có thể hook mới có thể patch. Vì vậy, function được biên dịch không có lệnh gọi ở entry sẽ hoàn toàn không thể patch. Đơn vị patch là toàn bộ function, không bao giờ là một dòng riêng bên trong function.

Phần khó hơn là chuyển đổi một hệ thống đang chạy một cách an toàn. Nếu code cũ vẫn đang chạy trên stack của một CPU khi bạn thay function, hệ thống sẽ có hành vi trộn lẫn giữa code cũ và mới. Linux upstream xử lý việc này bằng mô hình nhất quán theo từng task, được mô tả trong tài liệu kernel là một mô hình lai: "it uses kGraft's per-task consistency and syscall barrier switching combined with kpatch's stack trace switching." Các task chuyển sang code mới lần lượt từng task, chỉ khi kernel xác nhận task đó hiện không nằm bên trong function được patch. Trước khi mọi task chuyển xong, patch vẫn ở trạng thái chuyển tiếp.

Bạn có thể tự xem kết quả. Các patch đã áp dụng xuất hiện dưới /sys/kernel/livepatch. Mỗi patch có một thư mục riêng, bên trong liệt kê các function đã được patch.

ls /sys/kernel/livepatch/

Danh sách trống nghĩa là hiện không có live patch nào được nạp trong memory. Trên server mới, đây là trạng thái khởi đầu bình thường.

Những gì live kernel patching không thể khắc phục

Chỉ phần thân hàm được patch. Mọi thành phần khác thì không.

• Cấu trúc dữ liệu đã thay đổi. Nếu bản sửa từ upstream thêm một field vào struct hoặc thay đổi ý nghĩa của field hiện có, không có cách an toàn để viết lại các object đã được cấp phát và đang được sử dụng. Dự án kpatch nêu trực tiếp trường hợp tương đương: "Patches which modify statically allocated data are not directly supported." Có thể dùng shadow variable và callback để xử lý, nhưng phải viết thủ công cho từng patch, không được tự động hóa.
• Bản sửa trải rộng trên nhiều hàm cùng lúc. Bản sửa thay đổi thứ tự lock trên một nhóm hàm yêu cầu tất cả hàm đó thay đổi đồng thời. Mô hình nhất quán sẽ chuyển task thay vì đóng băng toàn bộ máy tại một thời điểm duy nhất.
• Mã khởi tạo. Các hàm được đánh dấu __init đã chạy và được giải phóng trước khi server của bạn hoạt động, nên không còn gì để chuyển hướng.
• Phiên bản kernel mới và tính năng mới. Live patching chỉ đưa bạn lên một patch level khác trong cùng một kernel series. Nó không bao giờ chuyển bạn từ series này sang series khác và cũng không thêm tính năng. Nếu muốn dùng thành phần có trong series mới hơn, chẳng hạn các thay đổi được đưa vào Linux 7.1, bạn phải cài kernel đó rồi boot vào kernel mới.
• Userspace. Canonical nêu rõ ranh giới này: "Canonical Livepatch does not patch userspace libraries like OpenSSL or glibc, because that is the responsibility of unattended-upgrades or a systems management tool." Một kernel đã được live patch nằm cạnh OpenSSL đã lỗi thời không phải là một server đã được patch. Vì vậy, hãy để unattended upgrades xử lý các package userspace trên cùng máy đó.

Dịch vụ của Ubuntu cũng có giới hạn về mức độ nghiêm trọng. Canonical cho biết dịch vụ này "patches kernel vulnerabilities with critical and high Common Vulnerability Scoring System (CVSS) and Ubuntu Priority ratings." Một mã định danh CVE (common vulnerabilities and exposures) chỉ một lỗ hổng cụ thể, còn CVSS là điểm số gắn với lỗ hổng đó. CVE kernel có mức medium sẽ được khắc phục trong package trên disk nhưng không được live patch. Vì vậy, bản sửa chỉ có trong kernel đang chạy sau lần reboot tiếp theo, không sớm hơn.

Các lựa chọn live kernel patching là gì?

Hiện có ba nhánh được sử dụng phổ biến, và cả ba đều điều khiển cùng một cơ chế kernel.

Canonical Livepatch được cung cấp thông qua Ubuntu Pro. Ubuntu Pro miễn phí cho mục đích sử dụng cá nhân. Canonical nêu rõ dịch vụ này “hiện tại và sẽ luôn miễn phí cho mục đích sử dụng cá nhân trên tối đa 5 máy vật lý”, và giới hạn này tăng lên 50 máy đối với thành viên chính thức của Ubuntu Community. Đây là giới hạn được ghi nhận trong tài liệu vào tháng 8 năm 2026. Sử dụng cho mục đích thương mại cần subscription trả phí. Phạm vi hỗ trợ được cấp theo từng kernel series và từng flavour. Dịch vụ hỗ trợ các kernel general availability (GA) của những bản phát hành long term support (LTS) được hỗ trợ, cùng với kernel hardware enablement (HWE) tương ứng, trên các flavour như generic, aws, azure, gcp, oracle, ibm và lowlatency. Hãy đối chiếu kernel của bạn với danh sách kernel do Canonical công bố trước khi dựa vào tính năng này.

KernelCare của TuxCare là một agent thương mại, hỗ trợ nhiều distribution, bao gồm cả những distribution không có service chính thức từ nhà phát triển. Cách cài đặt được ghi trong tài liệu là chạy vendor script, curl -s -L https://kernelcare.com/installer | bash, sau đó chạy /usr/bin/kcarectl --register KEY để cấp phép bằng key. Agent sẽ tự kiểm tra patch mới theo lịch riêng, còn /usr/bin/kcarectl --update sẽ buộc agent kiểm tra ngay. Hãy đọc installer trước khi pipe nó vào shell trên server quan trọng.

kpatch và kGraft là các dự án tiền thân. kGraft do SUSE phát triển, còn kpatch do Red Hat phát triển. Phần lõi live patching trong Linux upstream hiện nay là sự kết hợp của hai ý tưởng này. Bản thân kpatch đang được ngừng phát triển: README nêu rằng từ Linux 6.19, “dự án kpatch không còn được khuyến nghị và chuyển sang maintenance mode”, trong đó kpatch-build được thay thế bằng klp-build trong upstream kernel. Trên RHEL và các bản rebuild của RHEL, bạn nên dùng service riêng của distribution thay vì tự build patch.

Hãy lựa chọn dựa trên những gì distribution của bạn hỗ trợ và licence bạn được phép sử dụng. Kết quả ở cấp kernel là như nhau trong cả ba trường hợp.

Cách bật Canonical Livepatch trên Ubuntu

Trước tiên, hãy lấy token từ trang tài khoản Ubuntu Pro. Cả hai lệnh bên dưới đều cần kết nối mạng outbound hoạt động, vì client phải kết nối đến máy chủ của Canonical để attach tài khoản và tải các bản vá.

sudo pro attach TOKEN
sudo pro status

Chạy sudo pro attach mà không truyền token sẽ bắt đầu quy trình qua browser và in ra một mã để nhập trên trang của Canonical. Thao tác attach sẽ tự động bật các service được khuyến nghị. Trên bản phát hành LTS hiện tại, danh sách này có Livepatch. Dùng sudo pro attach --no-auto-enable nếu bạn muốn tự chọn các service.

Nếu Livepatch chưa được bật:

sudo pro enable livepatch
sudo canonical-livepatch status

Service này chạy từ snap canonical-livepatch, vì vậy snapd phải hoạt động thì bước bật mới hoàn tất. pro status in ra bảng gồm entitlement và trạng thái của các service. canonical-livepatch status in ra thông tin chi tiết theo từng kernel. Tài liệu của Canonical hiển thị output theo dạng sau:

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

Hai dòng chứa thông tin cần xác định. kernel state cho biết series bạn đang chạy có được service hỗ trợ hay không. Đây là dòng chuyển sang trạng thái lỗi khi bạn boot một kernel không được Livepatch hỗ trợ. patch state cho biết các bản vá áp dụng cho kernel đó đã thực sự được nạp hay chưa. Kernel được hỗ trợ nhưng chưa áp dụng bản vá là vấn đề của client. Kernel không được hỗ trợ là vấn đề của kernel, và không có cấu hình client nào khắc phục được.

Làm thế nào để biết máy đang chờ reboot?

Live patching loại bỏ tình huống khẩn cấp, nên trạng thái chờ reboot không còn rõ ràng. Bạn phải chủ động kiểm tra.

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

Package manager tạo /var/run/reboot-required khi một package đã cài cần restart để thay đổi có hiệu lực. Việc cài package linux-image mới luôn tạo file này. File .pkgs liệt kê các package đã yêu cầu restart. Nếu command đầu tiên trả về No such file or directory, không có package nào yêu cầu reboot kể từ lần boot gần nhất. Trên Ubuntu hiện tại, /var/run là symlink đến /run, nên dùng path nào cũng truy cập cùng một file.

Flag này nằm trong tmpfs và được reset sau mỗi lần boot. Vì vậy, hãy đối chiếu với chính kernel:

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

uname -r in ra kernel đang chạy. Command thứ hai in ra các kernel package đã cài trên disk. Nếu trong danh sách đó có linux-image mới hơn phiên bản mà uname -r báo cáo, máy đang chạy kernel cũ, bất kể trạng thái Livepatch là gì. Đây là kiểm tra quan trọng, vì live patching được thiết kế để giữ kernel đang chạy an toàn, không phải để cập nhật kernel lên phiên bản mới nhất.

Đối với phần userspace của cùng câu hỏi, needrestart được cài mặc định trên Ubuntu Server và liệt kê các service đang chạy nhưng vẫn giữ các library file đã bị xóa.

sudo needrestart -r l

Cặp flag -r l có nghĩa là “chỉ liệt kê”, nên command chỉ báo cáo và không thay đổi gì.

Vì sao yêu cầu reboot không bao giờ biến mất

Kernel trên disk không thay đổi. Live patches được nạp vào kernel đang chạy và không bao giờ được ghi vào boot image. Vì vậy, khi reboot, hệ thống khởi động bằng linux-image mà bootloader chọn. Sau đó, client Livepatch áp dụng lại những patch vẫn còn phù hợp. Trong khoảng thời gian giữa hai bước này, hệ thống đang chạy code chưa được patch. Đây là một lý do nữa để boot kernel hiện tại thay vì kernel cũ.

Phạm vi hỗ trợ được xác định theo từng kernel series, và các series sẽ bị ngừng hỗ trợ. Khi series đang chạy không còn nằm trong danh sách được hỗ trợ, dòng kernel state sẽ không còn báo coverage. Cách khắc phục duy nhất là dùng kernel mới hơn. Điều đó cần reboot.

Các bản sửa kernel có mức độ nghiêm trọng trung bình và thấp không bao giờ được live patch. Chúng nằm trong package trên disk và chỉ được áp dụng khi bạn boot.

Kernel chạy trong thời gian dài cũng tích lũy state mà việc patch không dọn sạch. Quan điểm của Canonical đáng được trích dẫn vì đây là cách nói chính xác: Livepatch “không thay thế cho việc reboot. Đây là công cụ giúp bạn kiểm soát tốt hơn bằng cách ngăn các lần reboot không được lên lịch.” Từ mang ý nghĩa chính ở đây là unscheduled. Bạn vẫn phải reboot. Bạn chỉ chọn thời điểm.

Cách lên lịch reboot và bảo đảm máy khởi động lại

Reboot VPS là thao tác một chiều nếu bạn không truy cập được console. Trước khi chạy reboot, hãy bảo đảm bạn có thể truy cập lại khi máy không khởi động trở lại.

• Xác nhận provider có cung cấp serial console hoặc giao diện VNC (virtual network computing) trong control panel, và mở sẵn ngay bây giờ thay vì đợi đến khi có sự cố.
• Kiểm tra dung lượng trống bằng df -h /boot. /boot đầy có thể khiến kernel package lỗi khi ghi initramfs (initial RAM filesystem), làm bootloader trỏ đến một image chưa được ghi hoàn tất.
• Giữ lại ít nhất một kernel cũ đã được xác nhận là hoạt động tốt. GRUB liệt kê kernel đó trong mục "Advanced options for Ubuntu". Boot bằng kernel này là cách khôi phục nhanh nhất khi kernel mới bị lỗi.
• Tìm hiểu rescue mode của provider trước khi cần dùng. Nếu console hiển thị initramfs prompt sau reboot, bạn sẽ sửa lỗi tại đó.

Sau đó, hãy reboot vào thời điểm bạn còn đang thức:

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

Lệnh này lên lịch reboot sau 5 phút và gửi thông báo cho những user đang đăng nhập. sudo shutdown -c sẽ hủy lịch reboot. Khi máy hoạt động trở lại, hãy xác nhận cả 2 phần:

uname -r
sudo canonical-livepatch status

uname -r phải hiển thị kernel mới hơn, còn output trạng thái phải cho biết series mới đã được áp dụng. Nếu máy hoàn toàn không hoạt động trở lại, nguyên nhân gần như luôn nằm ở boot path chứ không phải network. Khi đó, hãy làm theo hướng dẫn trong guide về VPS không boot sau khi update kernel.

Vì sao vẫn cần dọn các kernel cũ

Live patching làm vấn đề này nghiêm trọng hơn thay vì giải quyết nó, vì nó loại bỏ lý do phải reboot trong khi các package linux-image vẫn tiếp tục được cài đặt. Mỗi kernel cài một boot image, một initramfs, một cây modules và thường có thêm một package headers. Trên một VPS nhỏ có phân vùng /boot riêng chỉ vài trăm megabyte, 3 hoặc 4 kernel là đủ làm đầy phân vùng này.

/boot đầy sẽ khiến lần cài kernel tiếp theo thất bại. Khi đó, máy không thể nhận chính bản cập nhật mà nó cần. apt autoremove sẽ xóa các kernel cũ khi chúng đủ điều kiện, nhưng trên một máy không bao giờ reboot, chúng chưa chắc đã đủ điều kiện. Package manager không xóa một kernel mà bạn có thể vẫn đang chạy.

Vì vậy, hãy kiểm tra các kernel đã cài đặt, giữ lại kernel đang chạy và một kernel dự phòng đã xác nhận hoạt động tốt, rồi xóa các kernel còn lại bằng quy trình an toàn để xóa kernel cũ trên Ubuntu. Không bao giờ xóa kernel mà uname -r đang báo là kernel hiện tại.

FAQ

Live kernel patching có nghĩa là tôi không bao giờ phải reboot VPS?

Không. Live patch được nạp vào kernel đang chạy nhưng không được ghi vào boot image, nên linux-image trên disk vẫn giữ nguyên version tại thời điểm bạn boot. Canonical nêu rõ: Livepatch “không thay thế cho việc reboot. Đây là công cụ giúp bạn kiểm soát tốt hơn bằng cách ngăn các lần reboot ngoài lịch.” Phạm vi hỗ trợ cũng kết thúc khi kernel series của bạn bị ngừng duy trì, và các bản sửa kernel có mức độ nghiêm trọng trung bình không bao giờ được live patch. Hãy lên lịch maintenance reboot theo chu kỳ bạn chọn thay vì chờ đến khi hệ thống buộc phải reboot.

Làm thế nào để kiểm tra live kernel patching có thực sự áp dụng các bản vá?

Chạy sudo canonical-livepatch status và đọc 2 dòng. kernel state cho biết kernel series đang chạy có được service hỗ trợ hay không, còn patch state cho biết các bản vá cho kernel đó đã được nạp hay chưa. Bạn cũng có thể kiểm tra trực tiếp từ phía kernel bằng ls /sys/kernel/livepatch/. Lệnh này liệt kê 1 directory cho mỗi bản vá đã nạp. Kết quả trống nghĩa là hiện không có bản vá nào được áp dụng trong memory, bất kể client báo gì.

Ubuntu Pro có miễn phí trên VPS cá nhân không?

Có, trong giới hạn được công bố. Canonical nêu rằng Ubuntu Pro “đang và sẽ luôn miễn phí cho mục đích cá nhân trên tối đa 5 máy vật lý”, tăng lên 50 máy đối với thành viên Ubuntu Community chính thức, tính đến tháng 8 năm 2026. Sử dụng cho mục đích thương mại cần subscription trả phí. Bạn attach máy bằng sudo pro attach TOKEN, sử dụng token lấy từ trang tài khoản Ubuntu Pro, rồi enable service bằng sudo pro enable livepatch.

Vì sao CVE của kernel vẫn được liệt kê là chưa được sửa sau khi Livepatch chạy?

Thường có 1 trong 2 lý do. Bản sửa có thể nằm dưới ngưỡng mức độ nghiêm trọng, vì Canonical live patch “các lỗ hổng kernel có xếp hạng Critical và High theo Common Vulnerability Scoring System (CVSS) và Ubuntu Priority”, còn các trường hợp khác được xử lý bằng package trên disk. Hoặc bản sửa không thể biểu diễn dưới dạng thay đổi function body, chẳng hạn khi upstream thay đổi data structure. Live patching không thể thực hiện việc này an toàn trên các object đã được cấp phát. Cả 2 trường hợp đều được xử lý theo cùng một cách: cài kernel package đã cập nhật và boot vào kernel đó.

Live kernel patching hoàn toàn không hỗ trợ những gì?

Userspace. Canonical nêu rõ Livepatch “không patch userspace library như OpenSSL hoặc glibc, vì việc đó thuộc trách nhiệm của unattended-upgrades hoặc một systems management tool.” Livepatch cũng không thể cung cấp version kernel mới hoặc feature mới, vì nó chỉ thay thế function body bên trong series bạn đang chạy. Ngoài ra, nó không thể patch các function __init, vì những function này đã chạy xong và được giải phóng khỏi memory trước khi server hoạt động.