Live Kernel Patching vs Reboot VPS: Apa Bedanya?

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, lalu setiap pemanggilan fungsi lama dialihkan ke salinan baru tersebut sementara server tetap melayani trafik. Mekanisme ini menjelaskan manfaat live patching sekaligus hal-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 melakukan boot dari image kernel lama yang tersimpan di disk, dan setiap patch tersebut hanya berada di memori.

Live patching sering ditawarkan sebagai fitur dalam paket managed. Pada server unmanaged, Anda dapat mengaktifkannya sendiri dengan dua perintah. Hal ini perlu diketahui sebelum Anda membayar selisih harga antara VPS managed dan unmanaged.

Bagaimana cara kerja live kernel patching?

Kernel memiliki inti 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 berjalan dibuat dengan inti tersebut. Tanpa inti 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 digunakan. Ftrace menggunakan lokasi pemanggilan tersebut sebagai hook. Saat patch diterapkan, inti live patching mendaftarkan handler ftrace pada fungsi target. Handler tersebut kemudian mengalihkan eksekusi ke fungsi pengganti. Dokumentasi kernel menjelaskannya secara langsung: "Livepatching biasanya perlu mengalihkan kode di bagian paling awal saat memasuki 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 entry tersebut sama sekali tidak dapat di-patch. Selain itu, unit patching adalah satu fungsi utuh, bukan satu baris tertentu di dalam fungsi.

Bagian yang lebih sulit adalah mengganti kode pada sistem yang sedang berjalan dengan aman. Jika kode lama masih berjalan pada stack salah satu CPU saat fungsi diganti, perilakunya dapat merupakan campuran perilaku lama dan baru. Upstream Linux menangani hal ini dengan model konsistensi per-task. Dokumentasi kernel menjelaskannya sebagai mekanisme hibrida: "mekanisme ini menggunakan konsistensi per-task dan pengalihan syscall barrier milik kGraft, yang digabungkan dengan pengalihan stack trace milik kpatch." Task berpindah ke kode baru satu per satu, hanya saat kernel dapat memastikan bahwa task tersebut tidak sedang berada di dalam fungsi yang di-patch. Sampai semua task berpindah, patch berada dalam tahap transisi.

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

ls /sys/kernel/livepatch/

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

Hal yang tidak dapat diperbaiki oleh live kernel patching

Body fungsi akan di-patch. Selain itu, tidak.

• Struktur data yang berubah. Jika perbaikan upstream menambahkan field ke struct atau mengubah makna 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 dapat digunakan 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 pada 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 saat server Anda aktif, sehingga tidak ada lagi yang dapat dialihkan.
• Versi kernel dan fitur baru. Live patching hanya 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 menjelaskan batasannya 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 telah di-live patch di samping OpenSSL yang sudah usang bukanlah server yang telah di-patch. Karena itu, pastikan unattended upgrades menangani paket userspace pada server 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) mengidentifikasi satu kerentanan, sedangkan CVSS adalah skor yang terkait dengannya. CVE kernel dengan tingkat medium diperbaiki pada paket di disk dan tidak di-live patch. CVE tersebut masuk ke kernel yang sedang berjalan pada reboot berikutnya, bukan sebelumnya.

Apa saja opsi live kernel patching?

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

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

KernelCare, dari TuxCare, adalah agent komersial yang mencakup banyak distribusi, termasuk distribusi yang tidak memiliki layanan pihak pertama. 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, dan /usr/bin/kcarectl --update memaksa pemeriksaan. Baca installer tersebut sebelum menyalurkannya ke shell pada server yang penting bagi Anda.

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

Pilih berdasarkan dukungan distribusi Anda dan izin dari lisensi yang Anda miliki. Hasil pada tingkat kernel sama dalam setiap kasus.

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 client berkomunikasi dengan server Canonical untuk melakukan attach 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 attach otomatis mengaktifkan service yang direkomendasikan. Pada rilis LTS saat ini, ini mencakup Livepatch. Gunakan sudo pro attach --no-auto-enable jika Anda ingin memilih service sendiri.

Jika Livepatch belum aktif:

sudo pro enable livepatch
sudo canonical-livepatch status

Service berjalan dari snap canonical-livepatch. Karena itu, snapd harus berfungsi agar proses pengaktifan selesai. pro status menampilkan tabel service beserta entitlement dan statusnya. canonical-livepatch status menampilkan detail per kernel. Dokumentasi Canonical menampilkan output 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 series yang sedang Anda jalankan tercakup oleh service tersebut. Baris ini berubah menjadi status gagal ketika 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 client. Kernel yang tidak tercakup menunjukkan masalah pada kernel. Tidak ada pengaturan client yang dapat memperbaikinya.

Bagaimana cara mengetahui apakah reboot tertunda?

Live patching menghilangkan kondisi darurat, sehingga kebutuhan reboot yang tertunda 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 baru linux-image 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 boot. Pada Ubuntu saat ini, /var/run adalah symlink ke /run, sehingga kedua path mengarah ke file yang sama.

Flag tersebut berada di 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 di disk. Jika terdapat linux-image dalam daftar tersebut yang lebih baru daripada yang dilaporkan uname -r, berarti mesin menjalankan kernel lama, apa pun status Livepatch. Pemeriksaan inilah yang penting, karena live patching dirancang untuk menjaga kernel yang sedang berjalan tetap aman, bukan untuk menjadikannya versi terbaru.

Untuk bagian userspace dari pertanyaan yang sama, needrestart terpasang secara default di Ubuntu Server dan mencantumkan service yang masih menggunakan 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 tetap diperlukan

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

Cakupan berlaku untuk setiap 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. Pada rilis LTS, seri yang lebih baru biasanya tersedia sebagai kernel hardware enablement yang disertakan dalam point release seperti 26.04.1, sehingga penggantinya sudah tersedia di archive dan satu-satunya yang belum dilakukan adalah boot yang Anda jadwalkan.

Perbaikan kernel dengan tingkat keparahan sedang dan rendah tidak pernah diterapkan melalui live patching. Perbaikan tersebut tersimpan dalam paket di disk dan baru diterapkan saat Anda mem-boot kernel.

Kernel yang berjalan dalam waktu lama juga mengakumulasi state yang tidak dibersihkan oleh patching. Posisi Canonical sendiri layak dikutip karena disampaikan secara jelas: Livepatch "bukan pengganti reboot. Livepatch adalah alat yang memberi Anda lebih banyak kendali dengan mencegah reboot yang tidak terjadwal." Kata yang membawa makna utama di sini adalah tidak terjadwal. Anda tetap melakukan reboot. Anda yang memilih 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 masuk kembali saat mesin tidak kembali aktif.

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

Lakukan reboot pada waktu ketika Anda masih terjaga:

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

Perintah tersebut menjadwalkan reboot dalam lima menit 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 sekarang melaporkan kernel yang lebih baru, dan output status seharusnya melaporkan bahwa seri baru tersebut tercakup. Jika mesin sama sekali tidak kembali aktif, masalahnya hampir selalu berada pada jalur boot, bukan jaringan. Gunakan rute pemulihan dalam panduan VPS yang tidak dapat melakukan boot setelah pembaruan kernel.

Mengapa kernel lama tetap perlu dibersihkan

Live patching membuat masalah ini semakin buruk, bukan menyelesaikannya, karena kebutuhan untuk reboot berkurang sementara paket linux-image terus diinstal. Setiap kernel menginstal boot image, initramfs, tree modules, dan biasanya paket headers. Pada VPS kecil dengan partisi /boot terpisah yang hanya berukuran beberapa ratus megabyte, tiga atau empat kernel dapat memenuhi partisi tersebut.

/boot yang penuh kemudian menyebabkan instalasi kernel berikutnya gagal. Akibatnya, mesin tidak dapat menerima update yang justru dibutuhkannya. Jalur apt autoremove akan menghapus kernel lama setelah kernel tersebut memenuhi syarat, tetapi pada server yang tidak pernah reboot, kernel tersebut belum tentu memenuhi syarat. Package manager tidak akan menghapus kernel yang mungkin masih sedang Anda jalankan.

Jadi, periksa kernel yang terinstal, pertahankan kernel yang sedang berjalan dan satu fallback yang sudah dipastikan berfungsi, lalu hapus sisanya 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 lagi?

Tidak. Live patch dimuat ke dalam kernel yang sedang berjalan dan tidak ditulis ke dalam 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 jadwal yang Anda pilih, 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 langsung dari sisi kernel 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, terlepas dari informasi yang diberikan client.

Apakah Ubuntu Pro gratis pada VPS pribadi?

Ya, dalam batas yang telah didokumentasikan. Canonical menyatakan bahwa Ubuntu Pro "gratis 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 yang tersimpan di disk. Atau, perbaikan tersebut mungkin tidak dapat dinyatakan sebagai perubahan pada function body, misalnya ketika upstream mengubah data structure, yang tidak dapat ditangani live patching dengan aman pada objek yang sudah dialokasikan. Kedua kasus tersebut diselesaikan dengan cara yang sama: install package kernel yang telah diperbarui lalu boot ke kernel tersebut.

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

Userspace. Canonical menjelaskannya secara tegas bahwa Livepatch "tidak melakukan patch pada library userspace seperti OpenSSL atau glibc, karena hal tersebut merupakan tanggung jawab unattended-upgrades atau systems management tool." Livepatch juga tidak dapat menyediakan versi kernel baru atau fitur baru karena hanya mengganti function body di dalam seri kernel yang sedang Anda jalankan. Selain itu, Livepatch tidak dapat menerapkan patch pada function __init, karena function tersebut telah dijalankan dan memorinya telah dibebaskan saat server aktif.