Live kernel patching hay reboot VPS: Nên chọn 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, không cần reboot và không làm rớt kết nối. Một bản đã sửa của hàm được nạp dưới dạng kernel module. Mọi lệnh gọi đến hàm cũ được chuyển hướng sang bản 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.

Nó giúp bạn có thêm thời gian. Nó không loại bỏ yêu cầu reboot. Server đã được live patch 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 cung cấp như một tính năng của managed plan. Trên unmanaged box, bạn có thể tự enable bằng hai command. Bạn nên biết điều này 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 core hỗ trợ 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)

Dòng có nội dung CONFIG_LIVEPATCH=y cho biết kernel đang chạy được build với core này. Nếu không có core, không service live patching 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ị tác động. Ftrace dùng vị trí lệnh gọi đó làm hook. Khi áp dụng patch, core live patching đăng ký một ftrace handler cho function đích. Handler này chuyển execution sang function thay thế. Tài liệu kernel nêu rõ: "Livepatching thường cần chuyển hướng code ngay tại phần đầu của function, trước khi các tham số của function hoặc stack bị thay đổi theo bất kỳ cách nào."

Từ câu này có hai hệ quả, và cả hai đều quan trọng về sau. Chỉ function mà ftrace có thể hook mới có thể được patch. Vì vậy, function được biên dịch không có lệnh gọi ở entry point sẽ không thể được patch. Ngoài ra, đơn vị patch luôn là toàn bộ function, không bao giờ là một dòng riêng lẻ 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 cũ và mới trộn lẫn. Linux upstream xử lý việc này bằng mô hình nhất quán theo từng task. Tài liệu kernel mô tả đây là mô hình hybrid: "mô hình này kết hợp cơ chế nhất quán theo từng task và chuyển đổi syscall barrier của kGraft với cơ chế chuyển đổi stack trace của kpatch." Các task chuyển sang code mới từng task một, chỉ khi kernel xác định được task đó hiện không ở bên trong một function đã được patch. Cho đến khi mọi task đều đã chuyển xong, patch vẫn ở trạng thái chuyển tiếp.

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

ls /sys/kernel/livepatch/

Danh sách trống nghĩa là hiện không có live patch nào được load 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ể sửa

Live kernel patching chỉ vá phần thân hàm. Mọi thành phần khác đều không được vá.

• Cấu trúc dữ liệu đã thay đổi. Nếu bản sửa upstream thêm một trường vào struct hoặc thay đổi ý nghĩa của trường 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 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." Shadow variable và callback có thể dùng làm cách khắc phục, nhưng phải viết thủ công cho từng bản vá, không được thực hiện tự động.
• 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 trong một nhóm hàm cần thay đổi tất cả các hàm đó cùng lúc. 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 xong và được giải phóng trước khi server của bạn hoạt động, vì vậy không còn gì để chuyển hướng.
• Kernel version mới và feature 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 bao giờ thêm feature. Nếu muốn dùng thứ 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 đó và boot bằng kernel đó.
• 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 nhưng vẫn đi cùng OpenSSL cũ không phải là một server đã được vá, 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) đại diện cho một lỗ hổng, còn CVSS là điểm số gắn với lỗ hổng đó. CVE kernel có mức medium được sửa trong package trên disk nhưng không được live patch, vì vậy bản sửa chỉ được áp dụng vào kernel đang chạy ở 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 dòng công nghệ được dùng phổ biến, và tất cả đều điều khiển cùng một cơ chế của kernel.

Canonical Livepatch được cung cấp thông qua Ubuntu Pro. Ubuntu Pro miễn phí cho mục đích cá nhân. Canonical nêu rõ dịch vụ này “hiện đ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. Đây là giới hạn được ghi trong tài liệu 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í. Phạm vi hỗ trợ được cấp theo từng kernel series và từng flavour. Dịch vụ bao phủ 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) của chú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, do TuxCare cung cấp, là một agent thương mại hỗ trợ nhiều distribution, bao gồm cả những distribution không có dịch vụ first-party. Cách cài đặt được ghi trong tài liệu là chạy script của vendor, curl -s -L https://kernelcare.com/installer | bash, sau đó chạy /usr/bin/kcarectl --register KEY để dùng licence dựa trên key. Agent 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, kpatch do Red Hat phát triển, còn phần lõi live patching trong upstream Linux hiện nay là sự hợp nhất ý tưởng của cả hai. Bản thân kpatch đang được thu hẹp: 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 chọn dựa trên những gì distribution của bạn hỗ trợ và licence của bạn cho phép. Kết quả ở cấp kernel là như nhau trong mỗi trường hợp.

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

Trước tiên, lấy token từ trang tài khoản Ubuntu Pro của bạn. 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 server của Canonical để attach tài khoản và tải patch.

sudo pro attach TOKEN
sudo pro status

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

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

sudo pro enable livepatch
sudo canonical-livepatch status

Service chạy từ snap canonical-livepatch, vì vậy snapd phải hoạt động thì bước enable mới hoàn tất. pro status in ra bảng service cùng entitlement và trạng thái của từng service. canonical-livepatch status in ra thông tin chi tiết theo từng kernel. Tài liệu của Canonical minh họa 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 câu trả lời. 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 patch áp dụng cho kernel đó đã thực sự được load hay chưa. Kernel được hỗ trợ nhưng không có patch nào được áp dụng là vấn đề ở client. Kernel không được hỗ trợ là vấn đề ở kernel, và không có thiết lập 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 dễ nhận biết. Bạn phải tự 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 reboot. Nếu lệnh đầ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 nó với chính kernel:

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

uname -r in ra kernel đang chạy. Lệnh 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 vấn đề, needrestart được cài mặc định trên Ubuntu Server và liệt kê các service đang chạy vẫn giữ các file thư viện đã bị xóa.

sudo needrestart -r l

Cặp flag -r l có nghĩa là “chỉ liệt kê”, nên lệnh 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 đĩa không thay đổi. Live patch được nạp vào kernel đang chạy và không bao giờ được ghi vào boot image. Vì vậy, sau khi reboot, hệ thống sẽ chạy kernel mà linux-image bootloader chọn, rồi Livepatch client áp dụng lại các patch 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à thêm một lý do để 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 trong danh sách được hỗ trợ, dòng kernel state sẽ không còn báo phạm vi hỗ trợ. Cách khắc phục duy nhất là dùng kernel mới hơn. Điều đó cần reboot. Trên bản phát hành LTS, series mới hơn thường đến dưới dạng hardware enablement kernel được tích hợp vào point release như 26.04.1, nên kernel thay thế đã có sẵn trong archive và việc còn thiếu chỉ là một lần boot do bạn lên lịch.

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 đĩa và chỉ có hiệu lực khi bạn boot.

Các kernel chạy lâu ngày cũng tích lũy state mà patch không thể dọn sạch. Quan điểm của chính Canonical đáng được trích dẫn vì đây là cách diễn đạt chính xác: Livepatch “không thay thế cho 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à không được lên lịch. Bạn vẫn phải reboot. Bạn chọn thời điểm.

Cách lên lịch reboot để máy khởi động lại bình thường

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 chắc chắn bạn có thể đăng nhập lại khi máy không khởi động trở lại.

• Xác nhận provider 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 xảy ra 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ũ đã biết là hoạt động tốt. GRUB liệt kê kernel này trong mục "Advanced options for Ubuntu". Boot bằng kernel đó 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 thức để xử lý sự 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 lúc này phải báo kernel mới hơn, còn output trạng thái phải báo series mới đã được áp dụng. Nếu máy hoàn toàn không hoạt động trở lại, lỗi gần như luôn nằm ở boot path chứ không phải network. Khi đó, hãy dùng quy trình khôi phục trong hướng dẫn xử lý VPS không khởi động sau khi cập nhật 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ì máy không còn chịu áp lực 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 VPS nhỏ có phân vùng /boot riêng chỉ vài trăm megabyte, 3 hoặc 4 kernel có thể 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. Đây là cách một máy không thể nhận chính bản update mà nó cần. Quy trình apt autoremove sẽ xóa các kernel cũ khi chúng đủ điều kiện, nhưng trên máy không bao giờ reboot, các kernel đó chưa chắc đã đủ điều kiện. Package manager sẽ không loại bỏ kernel mà máy có thể vẫn đang chạy.

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

FAQ

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

Không. Live patch được nạp vào kernel đang chạy và không được ghi vào boot image, nên linux-image trên disk vẫn giữ nguyên version mà bạn đã boot. Canonical nói 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 không được lên lịch.” Phạm vi hỗ trợ cũng kết thúc khi kernel series của bạn bị retired, và các bản sửa kernel có mức độ nghiêm trọng trung bình hoàn toàn không đượ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 bạn 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 patch không?

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 patch dành cho kernel đó đã được nạp hay chưa. Bạn cũng có thể kiểm tra trực tiếp phía kernel bằng ls /sys/kernel/livepatch/. Lệnh này liệt kê một directory cho mỗi bản patch đã được nạp. Listing rỗng nghĩa là hiện không có bản patch 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ói 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 August 2026. Mục đích thương mại cần paid subscription. Bạn attach một máy bằng sudo pro attach TOKEN, sử dụng token lấy từ trang tài khoản Ubuntu Pro, sau đó enable service bằng sudo pro enable livepatch.

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

Thông thường có 1 trong 2 lý do. Bản sửa có thể nằm dưới ngưỡng severity, vì Canonical chỉ live patch “các lỗ hổng kernel có mức đánh giá Critical hoặc 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 có thể 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ể làm việc này an toàn trên các object đã được allocate. Cả 2 trường hợp đều xử lý theo cùng một cách: install kernel package đã được update và boot vào kernel đó.

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

Userspace. Canonical nói rõ Livepatch “không patch các 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 kernel version mới hoặc feature mới, vì nó chỉ thay thế function body bên trong series mà bạn đang chạy. Ngoài ra, nó không thể patch các function __init, vì các function này đã chạy và được giải phóng khỏi memory trước khi server hoạt động.