Live kernel patching vs but semula VPS: Mana lebih baik?

Apakah fungsi live kernel patching pada VPS

Live kernel patching menggunakan tampalan keselamatan kernel pada mesin yang sedang berjalan, tanpa perlu but semula dan tanpa memutuskan sambungan. Salinan fungsi yang telah dibaiki dimuatkan sebagai modul kernel, dan setiap panggilan kepada fungsi lama dialihkan ke salinan baharu sementara pelayan terus melayani trafik. Mekanisme tunggal ini menjelaskan kelebihan live patching serta perkara yang tidak mampu dilakukannya.

Ia memberikan masa tambahan. Ia tidak menggantikan keperluan untuk but semula. Pelayan yang telah menerima live patching selama enam bulan masih lagi berjalan menggunakan imej kernel lama pada cakera, dan setiap tampalan tersebut hanya wujud di dalam memori.

Live patching sering dipasarkan sebagai ciri pelan terurus. Pada pelayan tidak terurus, anda boleh mengaktifkannya sendiri dengan dua arahan, perkara yang wajar diketahui sebelum anda membayar perbezaan harga antara VPS terurus dan tidak terurus.

Bagaimanakah tampalan kernel secara langsung berfungsi?

Kernel mempunyai teras tampalan langsung terbina dalam, yang dikompilasi dengan CONFIG_LIVEPATCH. Semak kernel yang sedang berjalan untuk memastikannya:

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

Baris yang memaparkan CONFIG_LIVEPATCH=y bermakna kernel yang anda jalankan dibina dengan teras tersebut. Tanpanya, tiada servis tampalan langsung boleh berfungsi pada mesin tersebut.

Penyaluran semula itu sendiri menggunakan ftrace, iaitu pengesan fungsi kernel. Kebanyakan fungsi kernel dikompilasi dengan arahan panggilan di bahagian paling atas fungsi, sebelum argumen atau stack disentuh. Ftrace menggunakan tapak panggilan tersebut sebagai hook. Apabila tampalan digunakan, teras tampalan langsung mendaftarkan pengendali ftrace pada fungsi sasaran, dan pengendali tersebut menghantar pelaksanaan ke fungsi gantian sebaliknya. Dokumentasi kernel menyatakan dengan jelas: "Livepatching biasanya perlu menyalurkan semula kod pada permulaan entri fungsi sebelum parameter fungsi atau stack diubah suai dalam apa jua cara."

Dua akibat terhasil daripada ayat tersebut, dan kedua-duanya penting kemudian. Hanya fungsi yang boleh di-hook oleh ftrace yang boleh ditampal, jadi fungsi yang dikompilasi tanpa panggilan entri tersebut tidak boleh ditampal sama sekali. Unit tampalan adalah keseluruhan fungsi, bukan satu baris di dalamnya.

Bahagian yang lebih sukar ialah menukar sistem yang sedang berjalan dengan selamat. Jika kod lama masih berjalan pada stack CPU semasa anda menukar fungsi, anda akan mendapat campuran gelagat lama dan baharu. Linux upstream mengendalikan perkara ini dengan model konsistensi per-task, yang diterangkan dalam dokumentasi kernel sebagai hibrid: "ia menggunakan konsistensi per-task kGraft dan penukaran syscall barrier digabungkan dengan penukaran stack trace kpatch." Task berpindah ke kod baharu satu demi satu, hanya apabila kernel boleh menunjukkan bahawa task tersebut tidak berada di dalam fungsi yang ditampal. Sehingga setiap task berpindah, tampalan berada dalam keadaan transisi.

Anda boleh melihat hasilnya sendiri. Tampalan yang digunakan muncul di bawah /sys/kernel/livepatch, satu direktori bagi setiap tampalan, dengan fungsi yang ditampal disenaraikan di dalamnya.

ls /sys/kernel/livepatch/

Senarai kosong bermakna tiada tampalan langsung dimuatkan dalam memori, yang merupakan keadaan permulaan biasa pada pelayan baharu.

Perkara yang tidak boleh dibaiki oleh live kernel patching

Badan fungsi akan ditampal. Perkara lain tidak.

• Struktur data yang diubah. Jika pembaikan upstream menambah medan pada struct atau mengubah maksud medan sedia ada, tiada cara selamat untuk menulis semula objek yang telah diperuntukkan dan sedang digunakan. Projek kpatch menyatakan kes yang setara secara terus: "Patch yang mengubah suai data yang diperuntukkan secara statik tidak disokong secara langsung." Pemboleh ubah shadow dan callback wujud sebagai penyelesaian, namun ia ditulis secara manual bagi setiap patch, bukan secara automatik.
• Pembaikan yang tersebar merentasi beberapa fungsi serentak. Pembaikan yang mengubah susunan kunci (lock ordering) merentasi sekumpulan fungsi memerlukan kesemuanya diubah bersama, dan model konsistensi menukar tugas dan bukannya membekukan keseluruhan mesin pada satu ketika.
• Kod permulaan. Fungsi yang ditandakan __init telah pun dijalankan dan dibebaskan sebaik sahaja pelayan anda aktif, jadi tiada apa yang tinggal untuk dihalakan semula.
• Versi kernel baharu dan ciri baharu. Live patching memindahkan anda sepanjang tahap patch dalam satu siri kernel. Ia tidak pernah memindahkan anda dari satu siri ke siri seterusnya, dan ia tidak pernah menambah ciri baharu. Jika anda mahukan sesuatu daripada siri yang lebih baharu, seperti perubahan yang dimasukkan ke dalam Linux 7.1, anda perlu memasang kernel tersebut dan melakukan but semula.
• Userspace. Canonical menyatakan sempadan tersebut: "Canonical Livepatch tidak menampal pustaka userspace seperti OpenSSL atau glibc, kerana itu adalah tanggungjawab unattended-upgrades atau alat pengurusan sistem." Kernel yang ditampal secara live di samping OpenSSL yang lapuk bukanlah pelayan yang ditampal, jadi pastikan unattended upgrades mengendalikan pakej userspace pada mesin yang sama.

Terdapat juga sempadan tahap keterukan pada perkhidmatan Ubuntu. Canonical menyatakan ia "menampal kerentanan kernel dengan penarafan Common Vulnerability Scoring System (CVSS) kritikal dan tinggi serta penarafan Keutamaan Ubuntu." Pengecam CVE (common vulnerabilities and exposures) menamakan satu kelemahan, dan CVSS ialah skor yang dilampirkan padanya. CVE kernel yang dinilai sebagai sederhana dibaiki dalam pakej pada cakera dan tidak ditampal secara live, jadi ia hanya sampai ke kernel anda yang sedang berjalan pada but semula seterusnya dan bukan sebelumnya.

Apakah pilihan patching kernel secara langsung?

Terdapat tiga susur galur yang lazim digunakan, dan kesemuanya memacu jentera kernel yang sama.

Canonical Livepatch disampaikan melalui Ubuntu Pro. Ubuntu Pro adalah percuma untuk kegunaan peribadi, dan kenyataan Canonical menyatakan bahawa ia "adalah dan akan sentiasa percuma untuk kegunaan peribadi sehingga 5 mesin fizikal", meningkat kepada 50 mesin untuk ahli Komuniti Ubuntu rasmi. Itu adalah had yang didokumentasikan setakat Ogos 2026. Kegunaan komersial memerlukan langganan berbayar. Liputan diberikan mengikut siri kernel dan perisa, meliputi kernel general availability (GA) bagi keluaran long term support (LTS) yang disokong serta kernel hardware enablement (HWE) masing-masing, merentasi perisa seperti generic, aws, azure, gcp, oracle, ibm dan lowlatency. Semak kernel anda sendiri berbanding senarai kernel yang diterbitkan oleh Canonical sebelum anda bergantung kepadanya.

KernelCare, daripada TuxCare, ialah ejen komersial yang meliputi banyak pengedaran, termasuk yang tidak mempunyai perkhidmatan pihak pertama. Pemasangannya yang didokumentasikan ialah skrip vendor, curl -s -L https://kernelcare.com/installer | bash, diikuti oleh /usr/bin/kcarectl --register KEY untuk lesen berasaskan kunci. Ejen tersebut kemudian menyemak tampalan baharu mengikut jadualnya sendiri, dan /usr/bin/kcarectl --update memaksa pemeriksaan dilakukan. Baca pemasang sebelum anda menyalurkannya (pipe) ke shell pada pelayan yang penting bagi anda.

kpatch dan kGraft adalah pelopornya. kGraft datang daripada SUSE, kpatch daripada Red Hat, dan teras patching secara langsung dalam Linux hulu (upstream) hari ini adalah gabungan kedua-dua idea tersebut. kpatch sendiri sedang dihentikan: README-nya menyatakan bahawa mulai Linux 6.19 "projek kpatch telah ditamatkan dan berada dalam mod penyelenggaraan", dengan kpatch-build digantikan oleh klp-build dalam kernel hulu. Pada RHEL dan binaan semula (rebuilds) daripadanya, alat yang anda perlukan ialah perkhidmatan pengedaran itu sendiri dan bukannya membina tampalan secara manual.

Pilih berdasarkan apa yang disokong oleh pengedaran anda dan apa yang dibenarkan oleh lesen anda. Hasil pada peringkat kernel adalah sama dalam setiap kes.

Cara mendayakan Canonical Livepatch pada Ubuntu

Dapatkan token daripada halaman akaun Ubuntu Pro anda terlebih dahulu. Kedua-dua arahan di bawah memerlukan akses rangkaian keluar yang berfungsi, kerana klien akan berhubung dengan pelayan Canonical untuk melakukan pendaftaran dan mendapatkan patch.

sudo pro attach TOKEN
sudo pro status

Menjalankan sudo pro attach tanpa token akan memulakan aliran berasaskan pelayar dan memaparkan kod untuk dimasukkan ke laman web Canonical. Proses pendaftaran akan mendayakan perkhidmatan yang disyorkan secara automatik, yang merangkumi Livepatch pada keluaran LTS semasa. Gunakan sudo pro attach --no-auto-enable jika anda lebih suka memilih perkhidmatan tersebut sendiri.

Jika Livepatch belum diaktifkan:

sudo pro enable livepatch
sudo canonical-livepatch status

Perkhidmatan ini berjalan daripada snap canonical-livepatch, jadi snapd perlu berfungsi untuk melengkapkan langkah pendayaan. pro status akan mencetak jadual perkhidmatan berserta kelayakan dan statusnya. canonical-livepatch status akan mencetak perincian bagi setiap kernel, dan dokumentasi Canonical menunjukkan output dalam bentuk ini:

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

Dua baris mengandungi jawapan tersebut. kernel state menyatakan sama ada siri yang anda jalankan dilindungi oleh perkhidmatan tersebut atau tidak, dan baris ini akan menunjukkan status tidak sah apabila anda memuatkan kernel yang tidak disokong oleh Livepatch. patch state menyatakan sama ada patch yang terpakai untuk kernel tersebut telah dimuatkan atau tidak. Kernel yang dilindungi tetapi tiada patch dimuatkan adalah masalah klien. Kernel yang tidak dilindungi adalah masalah kernel, dan tiada tetapan klien yang dapat membaikinya.

Bagaimanakah cara untuk mengetahui sama ada but semula (reboot) diperlukan?

Live patching menghilangkan situasi kecemasan, jadi keperluan untuk but semula tidak lagi kelihatan jelas. Anda perlu mencarinya sendiri.

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

Pengurus pakej akan mencipta /var/run/reboot-required apabila pakej yang dipasang memerlukan but semula untuk berkuat kuasa, dan pakej linux-image yang baharu sentiasa menciptanya. Fail .pkgs menyenaraikan pakej yang membuat permintaan tersebut. Jika arahan pertama memberikan jawapan No such file or directory, tiada apa-apa yang meminta but semula sejak mesin kali terakhir dihidupkan. Pada Ubuntu semasa, /var/run merupakan symlink kepada /run, jadi kedua-dua laluan merujuk kepada fail yang sama.

Flag tersebut berada dalam tmpfs dan akan ditetapkan semula pada setiap but, jadi sahkan ia dengan kernel itu sendiri:

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

uname -r mencetak kernel yang sedang anda jalankan. Arahan kedua mencetak pakej kernel yang dipasang pada cakera. Jika terdapat linux-image dalam senarai tersebut yang lebih baharu daripada apa yang dilaporkan oleh uname -r, ini bermakna mesin sedang menjalankan kernel lama, tidak kira apa status Livepatch yang dipaparkan. Ini adalah semakan yang penting, kerana live patching dibina untuk menjadikan kernel yang sedang berjalan selamat, bukan untuk menjadikannya versi terkini.

Bagi bahagian userspace untuk soalan yang sama, needrestart dipasang secara lalai pada Ubuntu Server dan menyenaraikan servis yang sedang berjalan yang masih memegang fail pustaka (library files) yang telah dipadamkan.

sudo needrestart -r l

Gandingan flag -r l bermaksud "senaraikan sahaja", jadi ia hanya melaporkan dan tidak mengubah apa-apa.

Mengapa but semula tetap diperlukan

Kernel pada cakera tidak berubah. Live patch dimuatkan ke dalam kernel yang sedang berjalan dan tidak pernah ditulis ke dalam imej but, jadi but semula akan membawa anda ke linux-image yang dipilih oleh bootloader, dan klien Livepatch kemudian akan menggunakan semula patch yang masih relevan. Di antara kedua-dua detik tersebut, anda menjalankan kod yang tidak dipatch, yang merupakan satu lagi sebab untuk memulakan kernel terkini berbanding kernel lama.

Liputan adalah mengikut siri kernel, dan siri akan ditamatkan. Apabila siri yang anda jalankan tidak lagi berada dalam senarai yang disokong, baris kernel state berhenti melaporkan liputan, dan satu-satunya penyelesaian ialah kernel yang lebih baharu. Itu memerlukan but semula. Pada keluaran LTS, siri yang lebih baharu biasanya sampai kepada anda sebagai kernel pemboleh perkakasan (hardware enablement kernel) yang digabungkan ke dalam keluaran titik seperti 26.04.1, jadi penggantinya sudah tersedia dalam arkib dan apa yang kurang hanyalah but semula yang anda jadualkan.

Pembaikan kernel yang mempunyai tahap keterukan sederhana dan rendah tidak pernah dipatch secara langsung (live patched). Ia kekal dalam pakej pada cakera dan hanya sampai kepada anda apabila anda melakukan but semula.

Kernel yang berjalan dalam tempoh yang lama juga mengumpul keadaan (state) yang tidak dibersihkan oleh patching. Pendirian Canonical sendiri wajar dipetik, kerana ia adalah pendirian yang jujur: Livepatch "bukan pengganti untuk but semula. Ia adalah alat yang memberi anda lebih kawalan dengan menghalang but semula yang tidak dijadualkan." Perkataan yang membawa maksud di situ ialah tidak dijadualkan. Anda tetap perlu melakukan but semula. Anda yang memilih bila masanya.

Cara menjadualkan but semula yang akan kembali aktif

But semula VPS adalah tindakan sehala jika anda tidak boleh mencapai konsol. Sebelum anda menaip reboot, pastikan anda boleh masuk semula apabila mesin tidak kembali aktif.

• Sahkan pembekal anda menyediakan konsol bersiri atau paparan VNC (virtual network computing) dalam panel kawalan, dan bukanya sekarang dan bukannya semasa gangguan berlaku.
• Semak ruang kosong dengan df -h /boot. /boot yang penuh menyebabkan pakej kernel gagal semasa menulis initramfs (initial RAM filesystem), yang boleh menyebabkan entri bootloader menghala ke imej yang tidak selesai.
• Pastikan sekurang-kurangnya satu kernel lama yang diketahui berfungsi masih dipasang. GRUB menyenaraikannya di bawah "Advanced options for Ubuntu", dan memulakannya adalah pemulihan terpantas apabila kernel baharu gagal.
• Cari mod penyelamatan (rescue mode) pembekal anda sebelum anda memerlukannya. Jika konsol menunjukkan prompt initramfs selepas but semula, di situlah pembaikan dilakukan.

Kemudian, lakukan but semula pada waktu anda berjaga:

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

Perintah itu menjadualkan but semula dalam masa lima minit dan menghantar mesej kepada pengguna yang sedang log masuk. sudo shutdown -c membatalkannya. Apabila mesin kembali aktif, sahkan kedua-dua bahagian:

uname -r
sudo canonical-livepatch status

uname -r kini sepatutnya melaporkan kernel yang lebih baharu, dan output status sepatutnya melaporkan siri baharu tersebut sebagai dilindungi. Jika mesin tidak kembali aktif langsung, kerosakan hampir selalu berlaku pada laluan but dan bukannya rangkaian, dan laluan pemulihan adalah yang terdapat dalam panduan untuk VPS yang tidak boleh but selepas kemas kini kernel.

Mengapa kernel lama perlu dibersihkan

Live patching menjadikan masalah ini lebih buruk dan bukannya bertambah baik, kerana ia menghilangkan keperluan untuk but semula (reboot) sementara pakej linux-image terus dipasang. Setiap kernel memasang imej but, initramfs, pepohon modul dan biasanya pakej headers. Pada VPS kecil dengan partition /boot berasingan yang hanya bersaiz beberapa ratus megabait, tiga atau empat kernel sudah cukup untuk memenuhkan ruang tersebut.

Partition /boot yang penuh akan menyebabkan pemasangan kernel seterusnya gagal, dan inilah punca sesebuah mesin tidak dapat menerima kemas kini yang diperlukan. Laluan apt autoremove akan memadamkan kernel lama sebaik sahaja ia layak untuk dibuang, namun pada mesin yang tidak pernah but semula, kernel tersebut tidak selalu dianggap layak kerana pengurus pakej tidak akan membuang kernel yang mungkin sedang anda gunakan.

Oleh itu, semak kernel yang dipasang, kekalkan kernel yang sedang berjalan dan satu kernel sandaran yang berfungsi dengan baik, kemudian buang yang selebihnya menggunakan prosedur selamat untuk membuang kernel lama pada Ubuntu. Jangan sekali-kali membuang kernel yang dilaporkan oleh uname -r pada masa ini.

FAQ

Adakah live kernel patching bermaksud saya tidak perlu melakukan reboot pada VPS saya?

Tidak. Live patch dimuatkan ke dalam kernel yang sedang berjalan dan tidak ditulis ke dalam imej but, jadi linux-image pada cakera kekal pada versi yang anda butkan. Canonical menyatakan perkara ini secara terus: Livepatch "bukan pengganti untuk reboot. Ia adalah alat yang memberi anda lebih kawalan dengan mencegah reboot yang tidak dijadualkan." Liputan juga berakhir apabila siri kernel anda ditamatkan, dan pembaikan kernel tahap keterukan sederhana tidak pernah diberikan live patch sama sekali. Jadualkan reboot penyelenggaraan pada kekerapan yang anda pilih dan bukannya menunggu sehingga ia dipaksa ke atas anda.

Bagaimanakah cara saya menyemak sama ada live kernel patching benar-benar menggunakan patch?

Jalankan sudo canonical-livepatch status dan baca dua baris. kernel state melaporkan sama ada siri kernel anda yang sedang berjalan dilindungi oleh perkhidmatan tersebut, dan patch state melaporkan sama ada patch untuk kernel tersebut telah dimuatkan. Anda juga boleh menyemak bahagian kernel secara terus dengan ls /sys/kernel/livepatch/, yang menyenaraikan satu direktori bagi setiap patch yang dimuatkan. Senarai kosong bermakna tiada apa-apa yang di-patch dalam memori pada masa ini, tidak kira apa yang dinyatakan oleh klien.

Adakah Ubuntu Pro percuma pada VPS peribadi?

Ya, dalam had yang didokumenkan. Kenyataan Canonical ialah Ubuntu Pro "adalah dan akan sentiasa percuma untuk kegunaan peribadi sehingga 5 mesin fizikal", meningkat kepada 50 mesin untuk ahli Komuniti Ubuntu rasmi, setakat Ogos 2026. Kegunaan komersial memerlukan langganan berbayar. Anda menyambungkan mesin dengan sudo pro attach TOKEN menggunakan token daripada halaman akaun Ubuntu Pro anda, kemudian aktifkan perkhidmatan tersebut dengan sudo pro enable livepatch.

Mengapakah CVE kernel masih disenaraikan sebagai tidak dibaiki selepas Livepatch dijalankan?

Biasanya disebabkan oleh satu daripada dua sebab. Pembaikan tersebut mungkin berada di bawah ambang keterukan, kerana Canonical hanya memberikan live patch kepada "kerentanan kernel dengan penarafan Common Vulnerability Scoring System (CVSS) kritikal dan tinggi serta penarafan Keutamaan Ubuntu" dan membiarkan selebihnya kepada pakej pada cakera. Atau, pembaikan tersebut mungkin tidak dapat dinyatakan sebagai perubahan pada badan fungsi, contohnya apabila upstream mengubah struktur data, yang tidak boleh dilakukan oleh live patching dengan selamat pada objek yang telah diperuntukkan. Kedua-dua kes diselesaikan dengan cara yang sama: pasang pakej kernel yang dikemas kini dan but ke dalamnya.

Apakah yang tidak dilindungi oleh live kernel patching sama sekali?

Userspace. Canonical menyatakan dengan jelas bahawa Livepatch "tidak membaiki pustaka userspace seperti OpenSSL atau glibc, kerana itu adalah tanggungjawab unattended-upgrades atau alat pengurusan sistem." Ia juga tidak boleh menyampaikan versi kernel baharu atau ciri baharu, kerana ia hanya menggantikan badan fungsi di dalam siri yang anda sedang jalankan. Dan ia tidak boleh membaiki fungsi __init, yang telah pun dijalankan dan dibebaskan daripada memori sebaik sahaja pelayan dihidupkan.