Live Kernel Patching atau Reboot VPS: Mana yang Tepat?

Apa yang dilakukan live kernel patching pada VPS

Live kernel patching menerapkan perbaikan keamanan kernel pada mesin yang sedang berjalan, tanpa reboot dan tanpa memutus koneksi. Salinan fungsi yang telah diperbaiki dimuat sebagai modul kernel. Setiap pemanggilan fungsi lama kemudian dialihkan ke salinan baru tersebut, sementara server tetap melayani trafik. Mekanisme ini menjelaskan manfaat live patching sekaligus hal yang tidak dapat dilakukannya.

Live patching memberi waktu tambahan. Fitur ini tidak menghilangkan kebutuhan untuk reboot. Server yang telah menggunakan live patching selama enam bulan tetap dijalankan dari image kernel lama yang tersimpan di disk. Semua patch tersebut juga hanya ada di memori.

Live patching sering ditawarkan sebagai fitur paket terkelola. Pada server yang tidak dikelola, Anda dapat mengaktifkannya sendiri dengan dua perintah. Hal ini perlu diketahui sebelum Anda membayar selisih antara VPS yang dikelola dan yang tidak dikelola.

Bagaimana cara kerja live kernel patching?

Kernel memiliki core live patching bawaan yang dikompilasi bersama CONFIG_LIVEPATCH. Periksa kernel yang sedang berjalan:

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

Baris yang berisi CONFIG_LIVEPATCH=y berarti kernel yang sedang Anda gunakan dibangun dengan core tersebut. Tanpa core ini, tidak ada service live patching yang dapat melakukan apa pun pada mesin tersebut.

Pengalihan ini menggunakan ftrace, yaitu function tracer milik kernel. Sebagian besar fungsi kernel dikompilasi dengan instruksi pemanggilan di bagian paling awal fungsi, sebelum argumen atau stack diakses. Ftrace menggunakan lokasi pemanggilan tersebut sebagai hook. Saat patch diterapkan, core live patching mendaftarkan handler ftrace pada fungsi target, lalu handler tersebut mengalihkan eksekusi ke fungsi pengganti. Dokumentasi kernel menjelaskannya secara langsung: "Livepatching biasanya perlu mengalihkan kode tepat di awal entri fungsi, sebelum parameter fungsi atau stack diubah dengan cara apa pun."

Ada dua konsekuensi dari pernyataan tersebut, dan keduanya penting untuk bagian berikutnya. Hanya fungsi yang dapat di-hook oleh ftrace yang dapat di-patch. Jadi, fungsi yang dikompilasi tanpa pemanggilan pada entri tersebut sama sekali tidak dapat di-patch. Selain itu, unit patching adalah satu fungsi utuh, bukan satu baris di dalamnya.

Bagian yang lebih sulit adalah mengganti kode dengan aman pada sistem yang sedang berjalan. Jika kode lama masih berjalan pada stack salah satu CPU saat fungsi diganti, perilaku lama dan baru dapat tercampur. Linux upstream menangani hal ini dengan model konsistensi per-task, yang dijelaskan dalam dokumentasi kernel sebagai model hibrida: "model ini menggunakan konsistensi per-task dan pergantian syscall barrier dari kGraft, yang digabungkan dengan pergantian stack trace dari kpatch." Task berpindah ke kode baru satu per satu, hanya ketika kernel dapat memastikan bahwa task tersebut sedang tidak berada di dalam fungsi yang di-patch. Sampai semua task berpindah, patch berada dalam status transisi.

Anda dapat melihat hasilnya sendiri. Patch yang telah diterapkan muncul di bawah /sys/kernel/livepatch, dengan satu direktori untuk setiap patch dan daftar fungsi yang di-patch di dalamnya.

ls /sys/kernel/livepatch/

Daftar yang kosong berarti tidak ada live patch yang dimuat ke memori. Pada server baru, ini merupakan kondisi awal yang normal.

Hal yang tidak dapat diperbaiki dengan live kernel patching

Isi fungsi yang diubah akan ditambal. Selain itu, tidak.

• Struktur data yang berubah. Jika perbaikan upstream menambahkan field ke dalam struct atau mengubah arti field yang sudah ada, tidak ada cara yang aman untuk menulis ulang objek yang sudah dialokasikan dan sedang digunakan. Proyek kpatch menyatakan kasus yang setara secara langsung: "Patches which modify statically allocated data are not directly supported." Shadow variables dan callback tersedia sebagai solusi, tetapi harus ditulis secara manual untuk setiap patch, bukan dilakukan secara otomatis.
• Perbaikan yang tersebar pada beberapa fungsi sekaligus. Perbaikan yang mengubah urutan lock di antara sekelompok fungsi mengharuskan semuanya diubah secara bersamaan. Model konsistensinya memindahkan task, bukan membekukan seluruh mesin pada satu waktu.
• Kode inisialisasi. Fungsi yang ditandai __init sudah dijalankan dan dibebaskan ketika server Anda aktif, sehingga tidak ada lagi yang dapat dialihkan.
• Versi kernel baru dan fitur baru. Live patching memindahkan Anda ke tingkat patch lain dalam satu seri kernel. Live patching tidak pernah memindahkan Anda dari satu seri ke seri berikutnya dan tidak pernah menambahkan fitur. Jika Anda menginginkan sesuatu dari seri yang lebih baru, seperti perubahan yang masuk ke Linux 7.1, instal kernel tersebut lalu boot kernel itu.
• Userspace. Canonical menyatakan batas ini secara langsung: "Canonical Livepatch does not patch userspace libraries like OpenSSL or glibc, because that is the responsibility of unattended-upgrades or a systems management tool." Kernel yang sudah mendapat live patch dan OpenSSL yang kedaluwarsa bukanlah server yang sudah ditambal. Karena itu, pastikan unattended upgrades menangani paket userspace pada mesin yang sama.

Ada juga batas tingkat keparahan pada service Ubuntu. Canonical menyatakan bahwa service tersebut "patches kernel vulnerabilities with critical and high Common Vulnerability Scoring System (CVSS) and Ubuntu Priority ratings." Identifier CVE (common vulnerabilities and exposures) menunjukkan satu kerentanan, sedangkan CVSS adalah skor yang terkait dengan kerentanan tersebut. CVE kernel dengan tingkat keparahan medium diperbaiki dalam paket pada disk dan tidak mendapat live patch. Perbaikan tersebut masuk ke kernel yang sedang berjalan pada reboot berikutnya, bukan sebelumnya.

Apa saja opsi patching kernel secara live?

Ada tiga turunan yang umum digunakan, dan semuanya mengendalikan mekanisme kernel yang sama.

Canonical Livepatch disediakan melalui Ubuntu Pro. Ubuntu Pro gratis untuk penggunaan pribadi. Pernyataan Canonical menyebutkan bahwa layanan ini "is and always will be free for personal use on up to 5 physical machines", dan batas tersebut meningkat menjadi 50 mesin bagi anggota resmi Ubuntu Community. Itulah batas yang terdokumentasi per Agustus 2026. Penggunaan komersial memerlukan langganan berbayar. Cakupan diberikan untuk setiap seri kernel dan setiap flavour. Cakupan ini meliputi kernel general availability (GA) dari rilis long term support (LTS) yang didukung beserta kernel hardware enablement (HWE), pada flavour seperti generic, aws, azure, gcp, oracle, ibm, dan lowlatency. Periksa kernel Anda terhadap daftar kernel yang diterbitkan Canonical sebelum mengandalkannya.

KernelCare, dari TuxCare, adalah agent komersial yang mendukung banyak distribusi, termasuk distribusi yang tidak memiliki layanan first-party. Instalasi yang terdokumentasi menggunakan skrip vendor, curl -s -L https://kernelcare.com/installer | bash, lalu /usr/bin/kcarectl --register KEY untuk lisensi berbasis key. Setelah itu, agent memeriksa patch baru sesuai jadwalnya sendiri, sedangkan /usr/bin/kcarectl --update memaksa pemeriksaan. Baca installer sebelum menyalurkannya ke shell pada server yang penting bagi Anda.

kpatch dan kGraft adalah pendahulunya. kGraft berasal dari SUSE, kpatch berasal dari Red Hat, dan inti live patching pada upstream Linux saat ini merupakan penggabungan kedua gagasan tersebut. kpatch sendiri sedang dihentikan secara bertahap. README-nya menyatakan bahwa mulai Linux 6.19, "the kpatch project is deprecated and in maintenance mode", dengan kpatch-build yang digantikan oleh klp-build pada upstream kernel. Pada RHEL dan rebuild-nya, gunakan service milik distribusi tersebut, bukan membangun patch secara manual.

Tentukan pilihan berdasarkan dukungan distribusi Anda dan izin yang diberikan oleh lisensi Anda. Hasil pada tingkat kernel sama untuk setiap opsi.

Cara mengaktifkan Canonical Livepatch di Ubuntu

Dapatkan token dari halaman akun Ubuntu Pro terlebih dahulu. Kedua perintah di bawah memerlukan akses jaringan keluar yang berfungsi, karena klien berkomunikasi dengan server Canonical untuk menautkan akun dan mengambil patch.

sudo pro attach TOKEN
sudo pro status

Menjalankan sudo pro attach tanpa token akan memulai alur berbasis browser dan menampilkan kode yang harus dimasukkan di situs Canonical. Proses penautan otomatis mengaktifkan layanan yang direkomendasikan. Pada rilis LTS saat ini, layanan tersebut mencakup Livepatch. Gunakan sudo pro attach --no-auto-enable jika Anda ingin memilih layanan sendiri.

Jika Livepatch belum aktif:

sudo pro enable livepatch
sudo canonical-livepatch status

Layanan berjalan dari snap canonical-livepatch. Karena itu, snapd harus berfungsi agar proses pengaktifan selesai. pro status menampilkan tabel layanan beserta hak akses dan statusnya. canonical-livepatch status menampilkan detail per kernel. Dokumentasi Canonical menampilkan keluaran dalam bentuk berikut:

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 memberikan jawabannya. kernel state menunjukkan apakah seri yang sedang Anda jalankan tercakup oleh layanan. Baris ini akan menunjukkan masalah jika Anda mem-boot kernel yang tidak didukung Livepatch. patch state menunjukkan apakah patch yang berlaku untuk kernel tersebut benar-benar telah dimuat. Kernel yang tercakup tetapi tidak memiliki patch yang diterapkan menunjukkan masalah pada klien. Kernel yang tidak tercakup menunjukkan masalah pada kernel. Tidak ada pengaturan klien yang dapat memperbaikinya.

Bagaimana cara mengetahui apakah reboot diperlukan?

Live patching menghilangkan kondisi darurat, sehingga kebutuhan untuk melakukan reboot tidak lagi terlihat dengan jelas. Anda harus memeriksanya.

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

Package manager membuat /var/run/reboot-required ketika paket yang terpasang memerlukan restart agar perubahan berlaku, dan paket linux-image baru selalu membuatnya. File .pkgs mencantumkan paket yang memintanya. Jika perintah pertama menghasilkan No such file or directory, tidak ada yang meminta reboot sejak mesin terakhir kali melakukan boot. Pada Ubuntu saat ini, /var/run adalah symlink ke /run, sehingga kedua path tersebut mengarah ke file yang sama.

Penanda tersebut berada dalam tmpfs dan direset setiap kali boot. Karena itu, cocokkan hasilnya dengan kernel itu sendiri:

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

uname -r menampilkan kernel yang sedang Anda jalankan. Perintah kedua menampilkan paket kernel yang terpasang pada disk. Jika terdapat linux-image dalam daftar tersebut yang lebih baru daripada kernel yang dilaporkan oleh uname -r, berarti mesin sedang menjalankan kernel lama, terlepas dari status Livepatch. Pemeriksaan inilah yang penting, karena live patching dirancang untuk menjaga kernel yang sedang berjalan tetap aman, bukan untuk membuatnya selalu terbaru.

Untuk bagian userspace dari pertanyaan yang sama, needrestart terpasang secara default pada Ubuntu Server dan mencantumkan service yang sedang berjalan tetapi masih menahan file library yang telah dihapus.

sudo needrestart -r l

Pasangan flag -r l berarti "hanya tampilkan", sehingga perintah tersebut hanya melaporkan dan tidak mengubah apa pun.

Mengapa reboot tidak pernah benar-benar hilang

Kernel pada disk tidak berubah. Patch langsung dimuat ke kernel yang sedang berjalan dan tidak pernah ditulis ke image boot. Karena itu, reboot menjalankan linux-image yang dipilih bootloader, lalu klien Livepatch menerapkan kembali patch yang masih berlaku. Di antara kedua waktu tersebut, sistem menjalankan kode yang belum dipatch. Ini menjadi alasan tambahan untuk mem-boot kernel terbaru, bukan kernel lama.

Cakupan berlaku per seri kernel, dan seri kernel dapat dihentikan dukungannya. Saat seri yang sedang berjalan tidak lagi tercantum dalam daftar yang didukung, baris kernel state berhenti melaporkan cakupan. Satu-satunya solusi adalah menggunakan kernel yang lebih baru. Itu berarti reboot.

Perbaikan kernel dengan tingkat keparahan sedang dan rendah tidak pernah dipatch secara langsung. Perbaikan tersebut berada dalam paket di disk dan baru diterapkan saat Anda mem-boot sistem.

Kernel yang berjalan dalam waktu lama juga mengumpulkan state yang tidak dibersihkan oleh proses patching. Pernyataan Canonical sendiri layak dikutip karena bersifat jelas: Livepatch "bukan pengganti reboot. Livepatch adalah alat yang memberi Anda lebih banyak kendali dengan mencegah reboot yang tidak terjadwal." Kata yang membawa makna di sini adalah tidak terjadwal. Anda tetap melakukan reboot. Anda yang menentukan waktunya.

Cara menjadwalkan reboot agar sistem kembali aktif

Reboot VPS bersifat satu arah jika Anda tidak dapat mengakses console. Sebelum mengetik reboot, pastikan Anda dapat kembali masuk jika mesin tidak kembali aktif.

• Pastikan provider Anda menyediakan serial console atau tampilan VNC (virtual network computing) di control panel, lalu buka sekarang dan jangan menunggu hingga terjadi gangguan.
• Periksa ruang kosong dengan df -h /boot. /boot yang penuh membuat paket kernel gagal saat menulis initramfs (initial RAM filesystem). Kondisi ini dapat membuat entri bootloader menunjuk ke image yang tidak pernah selesai dibuat.
• Pertahankan setidaknya satu kernel lama yang telah dipastikan berfungsi. GRUB menampilkannya di bawah "Advanced options for Ubuntu", dan mem-boot kernel tersebut merupakan cara pemulihan tercepat saat kernel baru gagal.
• Cari tahu mode rescue provider Anda sebelum membutuhkannya. Jika console menampilkan prompt initramfs setelah reboot, perbaikan dilakukan dari sana.

Kemudian lakukan reboot pada waktu ketika Anda masih terjaga:

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

Perintah tersebut menjadwalkan reboot 5 menit kemudian dan mengirimkan pesan kepada pengguna yang sedang login. sudo shutdown -c membatalkannya. Setelah mesin kembali aktif, konfirmasikan kedua hal berikut:

uname -r
sudo canonical-livepatch status

uname -r seharusnya kini melaporkan kernel yang lebih baru, dan output status seharusnya melaporkan bahwa seri baru telah tercakup. Jika mesin sama sekali tidak kembali aktif, penyebabnya hampir selalu berada pada jalur boot, bukan jaringan. Gunakan jalur pemulihan dalam panduan tentang VPS yang tidak dapat boot setelah pembaruan kernel.

Mengapa kernel lama tetap perlu dibersihkan

Live patching justru memperburuk masalah ini, bukan mengatasinya, karena menghilangkan kebutuhan untuk reboot sementara paket linux-image terus terpasang. Setiap kernel memasang boot image, initramfs, modules tree, dan biasanya paket headers. Pada VPS kecil dengan partisi /boot terpisah berukuran beberapa ratus megabyte, tiga atau empat kernel saja sudah memenuhi partisi tersebut.

/boot yang penuh kemudian menggagalkan instalasi kernel berikutnya. Akibatnya, mesin tidak dapat memasang pembaruan yang justru dibutuhkannya. Jalur apt autoremove akan menghapus kernel lama setelah kernel tersebut memenuhi syarat untuk dihapus. Namun, pada server yang tidak pernah reboot, kernel lama belum tentu memenuhi syarat tersebut karena package manager tidak akan menghapus kernel yang mungkin masih sedang digunakan.

Jadi, periksa kernel yang terpasang. Pertahankan kernel yang sedang berjalan dan satu fallback yang sudah dipastikan berfungsi. Hapus kernel lainnya menggunakan prosedur aman untuk menghapus kernel lama di Ubuntu. Jangan pernah menghapus kernel yang saat ini dilaporkan oleh uname -r.

FAQ

Apakah live kernel patching berarti saya tidak perlu me-reboot VPS?

Tidak. Live patch dimuat ke kernel yang sedang berjalan dan tidak ditulis ke boot image, sehingga linux-image pada disk tetap menggunakan versi saat Anda melakukan boot. Canonical menyatakannya secara langsung: Livepatch "bukan pengganti reboot. Livepatch adalah alat yang memberi Anda lebih banyak kendali dengan mencegah reboot yang tidak terjadwal." Cakupan juga berakhir ketika seri kernel Anda tidak lagi didukung, dan perbaikan kernel dengan tingkat keparahan sedang tidak pernah diterapkan melalui live patch. Jadwalkan reboot pemeliharaan sesuai frekuensi yang Anda tentukan, bukan menunggu reboot dipaksakan.

Bagaimana cara memeriksa apakah live kernel patching benar-benar menerapkan patch?

Jalankan sudo canonical-livepatch status dan baca dua baris. kernel state melaporkan apakah seri kernel yang sedang berjalan tercakup oleh service tersebut, sedangkan patch state melaporkan apakah patch untuk kernel itu telah dimuat. Anda juga dapat memeriksa sisi kernel secara langsung dengan ls /sys/kernel/livepatch/, yang menampilkan satu direktori untuk setiap patch yang telah dimuat. Daftar yang kosong berarti saat ini tidak ada patch yang diterapkan di memori, apa pun yang dilaporkan client.

Apakah Ubuntu Pro gratis pada VPS pribadi?

Ya, dalam batas yang telah didokumentasikan. Canonical menyatakan bahwa Ubuntu Pro "sekarang dan akan selalu gratis untuk penggunaan pribadi pada hingga 5 mesin fisik", dan batasnya meningkat menjadi 50 mesin bagi anggota resmi Ubuntu Community, per August 2026. Penggunaan komersial memerlukan subscription berbayar. Hubungkan mesin dengan sudo pro attach TOKEN menggunakan token dari halaman akun Ubuntu Pro Anda, lalu aktifkan service dengan sudo pro enable livepatch.

Mengapa CVE kernel masih tercantum sebagai belum diperbaiki setelah Livepatch berjalan?

Biasanya ada satu dari dua alasan. Perbaikan tersebut mungkin berada di bawah ambang tingkat keparahan, karena Canonical menerapkan live patch pada "kerentanan kernel dengan peringkat critical dan high menurut Common Vulnerability Scoring System (CVSS) serta peringkat Ubuntu Priority", sedangkan perbaikan lainnya diserahkan kepada package pada disk. Atau, perbaikan tersebut mungkin tidak dapat dinyatakan sebagai perubahan pada isi fungsi, misalnya ketika upstream mengubah struktur data, yang tidak dapat dilakukan live patching dengan aman pada objek yang sudah dialokasikan. Kedua kasus tersebut diselesaikan dengan cara yang sama: instal package kernel yang telah diperbarui dan lakukan boot ke dalamnya.

Apa saja yang sama sekali tidak tercakup oleh live kernel patching?

Userspace. Canonical menyatakan dengan jelas bahwa Livepatch "tidak menerapkan patch pada library userspace seperti OpenSSL atau glibc, karena hal itu merupakan tanggung jawab unattended-upgrades atau alat pengelolaan sistem." Livepatch juga tidak dapat menyediakan versi kernel baru atau fitur baru, karena hanya mengganti isi fungsi dalam seri kernel yang sedang Anda jalankan. Selain itu, Livepatch tidak dapat menerapkan patch pada fungsi __init, yang telah selesai dijalankan dan dibebaskan dari memori ketika server sudah aktif.