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 akan dihalakan semula ke salinan baharu sementara pelayan terus melayani trafik. Mekanisme tunggal ini menjelaskan kelebihan serta batasan live patching.

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 (call instruction) 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 kepada 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 nanti. Hanya fungsi yang boleh di-hook oleh ftrace yang boleh ditampal, jadi fungsi yang dikompilasi tanpa panggilan entri tersebut tidak boleh ditampal sama sekali. Selain itu, unit tampalan adalah keseluruhan fungsi, bukan satu baris di dalam fungsi tersebut.

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 beralih kepada kod baharu satu demi satu, hanya apabila kernel boleh menunjukkan bahawa task tersebut tidak berada di dalam fungsi yang ditampal. Sehingga setiap task beralih, 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 menukar 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 bayangan (shadow variables) dan callback wujud sebagai penyelesaian sementara, tetapi 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 ditukar bersama, dan model konsistensi menukar tugas dan bukannya membekukan keseluruhan mesin pada satu saat yang tepat.
• Kod permulaan. Fungsi yang ditandakan __init telah pun dijalankan dan dibebaskan sebaik sahaja pelayan anda aktif, jadi tiada apa yang tinggal untuk diubah hala.
• 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 dalam Linux 7.1, anda perlu memasang kernel tersebut dan melakukan but semula.
• Userspace. Canonical menyatakan sempadan itu sendiri: "Canonical Livepatch tidak menampal pustaka userspace seperti OpenSSL atau glibc, kerana itu adalah tanggungjawab unattended-upgrades atau alat pengurusan sistem." Kernel yang ditampal secara langsung di samping OpenSSL yang lapuk bukanlah pelayan yang telah 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 sederhana akan dibaiki dalam pakej pada cakera dan tidak ditampal secara langsung, jadi ia hanya akan sampai ke kernel anda yang sedang berjalan pada but semula seterusnya dan bukan sebelumnya.

Apakah pilihan tampalan kernel secara langsung (live kernel patching)?

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

Canonical Livepatch disediakan 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 didokumenkan setakat Ogos 2026. Kegunaan komersial memerlukan langganan berbayar. Liputan diberikan mengikut siri kernel dan varian, meliputi kernel general availability (GA) bagi keluaran long term support (LTS) yang disokong serta kernel hardware enablement (HWE) masing-masing, merentasi varian 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. Pemasangan yang didokumenkan 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 tersebut sebelum anda menyalurkannya (pipe) ke shell pada pelayan yang penting bagi anda.

kpatch dan kGraft ialah leluhurnya. kGraft datang daripada SUSE, kpatch daripada Red Hat, dan teras tampalan 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 semulanya, 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 melampirkan akaun dan mengambil patch.

sudo pro attach TOKEN
sudo pro status

Menjalankan sudo pro attach tanpa token akan memulakan aliran berasaskan pelayar dan memaparkan kod untuk dimasukkan pada laman web Canonical. Proses melampirkan akaun 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 mencetak jadual perkhidmatan berserta kelayakan dan statusnya. canonical-livepatch status 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 ini adalah baris yang akan menunjukkan status buruk apabila anda memuatkan kernel yang tidak disokong oleh Livepatch. patch state menyatakan sama ada patch yang terpakai pada kernel tersebut benar-benar dimuatkan. 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 secara manual.

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 mencipta fail tersebut. 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 diboot. Pada Ubuntu semasa, /var/run ialah 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 memaparkan kernel yang sedang anda jalankan. Arahan kedua memaparkan 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 tidak dapat dielakkan

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 versi 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 ditampal, 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 akan berhenti melaporkan liputan, dan satu-satunya penyelesaian ialah kernel yang lebih baharu. Ini memerlukan but semula.

Pembaikan kernel tahap keterukan sederhana dan rendah tidak pernah diberikan live patch. Ia kekal dalam pakej pada cakera dan hanya sampai kepada anda apabila anda melakukan but semula.

Kernel yang berjalan untuk tempoh yang lama juga mengumpul status yang tidak dibersihkan oleh proses 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 mencegah but semula yang tidak dirancang." Perkataan yang membawa maksud di sini ialah tidak dirancang. Anda masih perlu melakukan but semula. Anda hanya memilih bila masanya.

Cara menjadualkan but semula yang akan kembali aktif

But semula VPS adalah tindakan sehala jika anda tidak dapat 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 pernah 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 penyelamat (rescue mode) pembekal anda sebelum anda memerlukannya. Jika konsol menunjukkan gesaan 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 lima minit dari sekarang 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 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 dapat but selepas kemas kini kernel.

Mengapa kernel lama perlu dibersihkan

Live patching menjadikan masalah ini lebih buruk, kerana ia menghilangkan keperluan untuk but semula 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 bersaiz beberapa ratus megabait, tiga atau empat kernel sudah cukup untuk memenuhkan ruang tersebut.

/boot yang penuh akan menyebabkan pemasangan kernel seterusnya gagal, yang mengakibatkan mesin tidak dapat menerima kemas kini yang diperlukan. Laluan apt autoremove akan memadamkan kernel lama sebaik sahaja ia layak, tetapi pada mesin yang tidak pernah but semula, kernel tersebut tidak sentiasa layak kerana pengurus pakej tidak akan membuang kernel yang mungkin masih anda gunakan.

Oleh itu, semak perkara yang telah dipasang, kekalkan kernel yang sedang berjalan dan satu kernel sandaran yang diketahui berfungsi, 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 bermakna saya tidak perlu but semula 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 but. Canonical menyatakan perkara ini secara terus: Livepatch "bukan pengganti untuk but semula. Ia adalah alat yang memberi anda lebih kawalan dengan mencegah but semula yang tidak dirancang." Liputan juga berakhir apabila siri kernel anda ditamatkan, dan pembaikan kernel tahap keseriusan sederhana tidak pernah diberikan live patch. Jadualkan but semula 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 itu 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 lampirkan mesin dengan sudo pro attach TOKEN menggunakan token daripada halaman akaun Ubuntu Pro anda, kemudian aktifkan perkhidmatan 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 keseriusan, kerana Canonical 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 boleh dinyatakan sebagai perubahan kepada 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 langsung oleh live kernel patching?

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 pada masa pelayan dihidupkan.