VPS üzerinde canlı çekirdek yamalama nasıl yapılır?

VPS üzerinde canlı çekirdek yamalamanın işlevi

Canlı çekirdek yamalama (live kernel patching), çalışan bir makineye, yeniden başlatma gerektirmeden ve bağlantıları koparmadan çekirdek güvenlik düzeltmelerini uygular. Bir fonksiyonun düzeltilmiş kopyası çekirdek modülü olarak yüklenir ve sunucu trafiği karşılamaya devam ederken, eski fonksiyona yapılan her çağrı yeni kopyaya yönlendirilir. Bu mekanizma, canlı yamalamanın ne işe yaradığını ve neleri yapamayacağını açıklar.

Bu yöntem zaman kazandırır. Yeniden başlatma ihtiyacını ortadan kaldırmaz. Altı aydır canlı yamalanan bir sunucu, disk üzerinde hala eski çekirdek imajı ile açılmış durumdadır ve bu yamaların her biri yalnızca bellekte yaşar.

Canlı yamalama genellikle yönetilen bir hizmet planının özelliği olarak pazarlanır. Yönetilmeyen bir sunucuda ise bunu iki komutla kendiniz etkinleştirebilirsiniz; bu durum, yönetilen ve yönetilmeyen bir VPS arasındaki fiyat farkını ödemeden önce bilinmesi gereken bir noktadır.

Canlı çekirdek yamalama nasıl çalışır?

Çekirdek, CONFIG_LIVEPATCH ile derlenen yerleşik bir canlı yamalama çekirdeğine sahiptir. Çalışan çekirdeğinizde bunun olup olmadığını kontrol edin:

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

CONFIG_LIVEPATCH=y yazan bir satır, çalıştırdığınız çekirdeğin bu çekirdek özelliğiyle derlendiği anlamına gelir. Bu özellik olmadan, hiçbir canlı yamalama servisi o makinede işlem yapamaz.

Yönlendirme işlemi, çekirdeğin fonksiyon izleyicisi olan ftrace'i kullanır. Çoğu çekirdek fonksiyonu, argümanlara veya yığına (stack) dokunulmadan hemen önce, fonksiyonun en başında bir çağrı komutuyla derlenir. Ftrace, bu çağrı noktasını bir kanca (hook) olarak kullanır. Bir yama uygulandığında, canlı yamalama çekirdeği hedef fonksiyon üzerinde bir ftrace işleyicisi kaydeder ve işleyici, yürütmeyi bunun yerine yedek fonksiyona yönlendirir. Çekirdek belgeleri bunu açıkça belirtir: "Canlı yamalama genellikle kodun, fonksiyon parametreleri veya yığın herhangi bir şekilde değiştirilmeden önce, fonksiyon girişinin en başında yönlendirilmesini gerektirir."

Bu cümleden iki sonuç çıkar ve her ikisi de daha sonra önem kazanır. Yalnızca ftrace'in kanca atabildiği fonksiyonlar yamalanabilir; bu nedenle, bu giriş çağrısı olmadan derlenen bir fonksiyon hiçbir şekilde yamalanamaz. Ayrıca yamalama birimi tek bir satır değil, fonksiyonun tamamıdır.

Daha zor olan kısım, çalışan bir sistemi güvenli bir şekilde değiştirmektir. Fonksiyonu değiştirdiğiniz sırada eski kod bazı işlemcilerin yığınında çalışmaya devam ediyorsa, eski ve yeni davranışın bir karışımını elde edersiniz. Yukarı akış (upstream) Linux bunu, çekirdek belgelerinde hibrit olarak tanımlanan görev bazlı bir tutarlılık modeliyle yönetir: "kGraft'ın görev bazlı tutarlılığını ve sistem çağrısı bariyer geçişini, kpatch'in yığın izleme geçişiyle birleştirir." Görevler, yalnızca çekirdek o görevin o anda yamalı bir fonksiyonun içinde olmadığını kanıtlayabildiğinde yeni koda geçer. Her görev taşınana kadar yama geçiş aşamasındadır.

Sonucu kendiniz görebilirsiniz. Uygulanan yamalar, her yama için bir dizin olacak şekilde /sys/kernel/livepatch altında görünür ve yamalı fonksiyonlar bunların içinde listelenir.

ls /sys/kernel/livepatch/

Boş bir liste, bellekte hiçbir canlı yamanın yüklü olmadığı anlamına gelir; bu da yeni bir sunucuda normal başlangıç durumudur.

Canlı çekirdek yamalamanın düzeltemeyeceği durumlar

Fonksiyon gövdeleri yamalanabilir. Bunun dışındaki hiçbir şey yamalanamaz.

• Değiştirilmiş veri yapıları. Eğer yukarı yönlü (upstream) bir düzeltme, bir struct yapısına yeni bir alan eklerse veya mevcut bir alanın anlamını değiştirirse, halihazırda tahsis edilmiş ve kullanımda olan nesneleri yeniden yazmanın güvenli bir yolu yoktur. kpatch projesi bu durumu doğrudan şu şekilde ifade eder: "Statik olarak tahsis edilmiş verileri değiştiren yamalar doğrudan desteklenmez." Gölge değişkenler ve geri çağırmalar (callbacks) bir geçici çözüm olarak mevcuttur ancak bunlar otomatik değil, her yama için elle yazılır.
• Birden fazla fonksiyona yayılan düzeltmeler. Bir grup fonksiyon genelinde kilit sıralamasını (lock ordering) değiştiren bir düzeltme, tüm bu fonksiyonların aynı anda değişmesini gerektirir; tutarlılık modeli ise tüm makineyi tek bir anda dondurmak yerine görevleri değiştirir.
• Başlatma kodu. __init olarak işaretlenmiş fonksiyonlar, sunucunuz ayağa kalktığında zaten çalışmış ve bellekten serbest bırakılmış durumdadır; bu nedenle yönlendirilecek bir kod parçası kalmamıştır.
• Yeni çekirdek sürümleri ve yeni özellikler. Canlı yamalama, sizi aynı çekirdek serisi içerisinde bir yama seviyesinden diğerine taşır. Sizi bir seriden diğerine asla geçirmez ve yeni bir özellik eklemez. Daha yeni bir seriden bir şeye ihtiyaç duyarsanız, örneğin Linux 7.1 ile gelen değişiklikler, o çekirdeği kurmanız ve sistemi onunla başlatmanız gerekir.
• Kullanıcı alanı (Userspace). Canonical bu sınırı net bir şekilde belirtir: "Canonical Livepatch, OpenSSL veya glibc gibi kullanıcı alanı kütüphanelerini yamalamaz; çünkü bu, unattended-upgrades veya bir sistem yönetim aracının sorumluluğundadır." Güncel olmayan bir OpenSSL kütüphanesinin yanındaki canlı yamalanmış bir çekirdek, yamalanmış bir sunucu anlamına gelmez; bu nedenle kullanıcı alanı paketlerini yöneten unattended upgrades aracını aynı sunucuda aktif tutun.

Ubuntu'nun servisinde bir önem derecesi sınırı da mevcuttur. Canonical, "çekirdek açıklarını kritik ve yüksek Common Vulnerability Scoring System (CVSS) puanları ve Ubuntu Öncelik derecelendirmelerine göre yamaladığını" belirtir. Bir CVE (common vulnerabilities and exposures) tanımlayıcısı tek bir kusuru adlandırır ve CVSS buna eklenmiş puandır. Orta dereceli bir çekirdek CVE'si, disk üzerindeki pakette düzeltilir ve canlı yamalanmaz; bu nedenle çalışan çekirdeğinize bir sonraki yeniden başlatmada ulaşır, daha önce değil.

Canlı çekirdek yamalama seçenekleri nelerdir?

Yaygın olarak kullanılan üç ana hat mevcuttur ve bunların tümü aynı çekirdek mekanizmasını kullanır.

Canonical Livepatch, Ubuntu Pro aracılığıyla sunulur. Ubuntu Pro kişisel kullanım için ücretsizdir ve Canonical'ın ifadesiyle "5 fiziksel makineye kadar kişisel kullanım için ücretsizdir ve her zaman ücretsiz kalacaktır"; bu sayı resmi Ubuntu Topluluğu üyeleri için 50 makineye kadar çıkmaktadır. Ağustos 2026 itibarıyla belgelenen sınır budur. Ticari kullanım ücretli abonelik gerektirir. Kapsam, çekirdek serisine ve sürümüne göre belirlenir; desteklenen uzun süreli destek (LTS) sürümlerinin genel kullanıma açık (GA) çekirdeklerini ve bunların donanım etkinleştirme (HWE) çekirdeklerini; generic, aws, azure, gcp, oracle, ibm ve lowlatency gibi sürümler genelinde kapsar. Güvenmeden önce kendi çekirdeğinizi Canonical'ın yayınladığı çekirdek listesiyle karşılaştırın.

TuxCare tarafından sunulan KernelCare, birinci taraf hizmeti olmayanlar da dahil olmak üzere birçok dağıtımı kapsayan ticari bir aracıdır. Belgelenen kurulum yöntemi bir tedarikçi betiği olan curl -s -L https://kernelcare.com/installer | bash ve ardından anahtar tabanlı lisanslama için /usr/bin/kcarectl --register KEY komutudur. Aracı daha sonra kendi zamanlamasına göre yeni yamaları kontrol eder; /usr/bin/kcarectl --update ise manuel bir kontrolü zorunlu kılar. Önem verdiğiniz bir sunucuda bir kabuğa yönlendirmeden önce yükleyiciyi mutlaka okuyun.

kpatch ve kGraft öncülerdir. kGraft SUSE'den, kpatch ise Red Hat'ten gelmiştir ve günümüzde ana hat (upstream) Linux'taki canlı yamalama çekirdeği, her iki fikrin birleşimidir. kpatch projesi sona ermektedir: README dosyası, Linux 6.19 sürümünden itibaren "kpatch projesinin kullanımdan kaldırıldığını ve bakım modunda olduğunu" belirtmekte olup kpatch-build, ana hat çekirdeğinde klp-build ile değiştirilmektedir. RHEL ve türevlerinde, yamaları elle oluşturmak yerine dağıtımın kendi sunduğu hizmeti kullanmanız gerekir.

Dağıtımınızın neyi desteklediğine ve lisansınızın neye izin verdiğine göre seçim yapın. Çekirdek seviyesindeki sonuç her durumda aynıdır.

Ubuntu üzerinde Canonical Livepatch nasıl etkinleştirilir

Öncelikle Ubuntu Pro hesap sayfanızdan bir token alın. Aşağıdaki her iki komut da dış dünyaya açık bir ağ bağlantısı gerektirir; çünkü istemci, sisteme bağlanmak ve yamaları çekmek için Canonical sunucularıyla iletişim kurar.

sudo pro attach TOKEN
sudo pro status

sudo pro attach komutunu bir token belirtmeden çalıştırmak, tarayıcı tabanlı bir süreci başlatır ve Canonical'ın sitesine girmeniz için bir kod üretir. Sistemin bağlanması, önerilen servisleri otomatik olarak etkinleştirir; güncel bir LTS sürümünde bu servisler arasında Livepatch de bulunur. Servisleri kendiniz seçmek isterseniz sudo pro attach --no-auto-enable komutunu kullanın.

Eğer Livepatch henüz açık değilse:

sudo pro enable livepatch
sudo canonical-livepatch status

Servis canonical-livepatch snap paketi üzerinden çalışır, bu nedenle etkinleştirme adımının tamamlanabilmesi için snapd servisinin çalışır durumda olması gerekir. pro status komutu, servislerin yetkilendirme ve durum bilgilerini içeren bir tablo yazdırır. canonical-livepatch status komutu çekirdek bazlı ayrıntıları gösterir; Canonical dokümantasyonu bu çıktıyı şu şekilde sunar:

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

İki satır cevabı içerir. kernel state, kullandığınız serinin servis tarafından desteklenip desteklenmediğini belirtir; Livepatch tarafından desteklenmeyen bir çekirdek ile önyükleme yaptığınızda bu satır hata verir. patch state ise ilgili çekirdeğe uygulanacak yamaların yüklü olup olmadığını gösterir. Desteklenen bir çekirdekte yama uygulanmamış olması bir istemci sorunudur. Desteklenmeyen bir çekirdek ise çekirdek kaynaklı bir sorundur ve hiçbir istemci ayarı bunu düzeltemez.

Yeniden başlatmanın gerekli olup olmadığını nasıl anlarım?

Canlı yamalama (live patching) aciliyeti ortadan kaldırır, bu nedenle bekleyen bir yeniden başlatma durumu belirginliğini yitirir. Bunu ayrıca kontrol etmeniz gerekir.

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

Paket yöneticisi, yüklü bir paketin etkili olması için yeniden başlatma gerektiğinde /var/run/reboot-required dosyasını oluşturur; yeni bir linux-image paketi ise bu dosyayı her zaman oluşturur. .pkgs dosyası, hangi paketlerin yeniden başlatma talep ettiğini listeler. İlk komut No such file or directory yanıtını verirse, makinenin son açılışından bu yana hiçbir paket yeniden başlatma talebinde bulunmamıştır. Güncel Ubuntu sürümlerinde /var/run, /run dosyasına giden bir sembolik bağdır (symlink), dolayısıyla her iki yol da aynı dosyaya erişir.

Bu işaret (flag) tmpfs içinde yer alır ve her açılışta sıfırlanır, bu yüzden durumu çekirdeğin kendisi üzerinden doğrulayın:

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

uname -r komutu, o an çalışan çekirdek sürümünü yazdırır. İkinci komut ise diskte yüklü olan çekirdek paketlerini listeler. Bu listede uname -r çıktısından daha yeni bir linux-image bulunması, Livepatch durumundan bağımsız olarak makinenin eski bir çekirdek üzerinde çalıştığı anlamına gelir. Önemli olan kontrol budur; çünkü canlı yamalama, çalışan çekirdeği güvenli kılmak için tasarlanmıştır, onu güncel tutmak için değil.

Aynı sorunun kullanıcı alanı (userspace) tarafı için, Ubuntu Server üzerinde varsayılan olarak yüklü gelen needrestart, silinmiş kütüphane dosyalarını hala bellekte tutan çalışan servisleri listeler.

sudo needrestart -r l

-r l işaret çifti "yalnızca listele" anlamına gelir, bu nedenle herhangi bir değişiklik yapmadan sadece raporlama sağlar.

Yeniden başlatma gereksinimi neden ortadan kalkmaz

Disk üzerindeki kernel değişmez. Live patch'ler çalışan kernel'a yüklenir ve boot imajına asla yazılmaz; bu nedenle yeniden başlatma işlemi, bootloader'ın seçtiği linux-image sürümüyle sistemi açar ve Livepatch istemcisi, geçerliliğini koruyan yamaları tekrar uygular. Bu iki aşama arasında yamalanmamış kod çalıştırırsınız; bu durum, eski bir kernel yerine güncel bir kernel ile sistemi başlatmak için bir başka nedendir.

Kapsam, kernel serisine göredir ve seriler zamanla kullanımdan kaldırılır. Çalışan seriniz desteklenenler listesinden çıktığında, kernel state satırı kapsam bildirmeyi durdurur ve tek çözüm daha yeni bir kernel kullanmaktır. Bu da bir yeniden başlatma gerektirir.

Orta ve düşük önem derecesindeki kernel düzeltmeleri asla live patch ile uygulanmaz. Bu düzeltmeler diskteki paket içerisinde bekler ve yalnızca sistemi yeniden başlattığınızda devreye girer.

Uzun süre çalışan kernel'lar, yama işleminin temizleyemediği durumlar da biriktirir. Canonical'ın kendi duruşu, dürüst bir yaklaşım olduğu için alıntılanmaya değerdir: Livepatch "yeniden başlatmanın bir alternatifi değildir. Plansız yeniden başlatmaları önleyerek size daha fazla kontrol sağlayan bir araçtır." Buradaki anlamı taşıyan kelime plansız ifadesidir. Yine de yeniden başlatırsınız. Ancak zamanlamasına siz karar verirsiniz.

Yeniden başlatma sonrası erişim sağlayabileceğiniz bir sistem nasıl planlanır

Konsola erişemediğiniz durumlarda bir VPS yeniden başlatması tek yönlü bir işlemdir. reboot komutunu girmeden önce, makine geri gelmediğinde sisteme tekrar girebileceğinizden emin olun.

• Servis sağlayıcınızın kontrol panelinde seri konsol veya VNC (virtual network computing) görünümü sunduğunu doğrulayın ve bunu kesinti anında değil, şimdi açın.
• df -h /boot ile boş alanı kontrol edin. Dolu bir /boot, initramfs (initial RAM filesystem) yazılırken kernel paketinin başarısız olmasına neden olur; bu durum, bootloader girişinin tamamlanmamış bir imaja işaret etmesine yol açabilir.
• En az bir adet sorunsuz çalıştığı bilinen eski bir kerneli sistemde tutun. GRUB bunu "Advanced options for Ubuntu" altında listeler; yeni bir kernel başarısız olduğunda bu kernel ile başlatma yapmak en hızlı kurtarma yöntemidir.
• İhtiyaç duymadan önce servis sağlayıcınızın kurtarma modunu (rescue mode) bulun. Yeniden başlatma sonrasında konsolda bir initramfs istemi görünüyorsa, onarım burada yapılır.

Ardından, uyanık olduğunuz bir zamanda yeniden başlatmayı planlayın:

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

Bu komut, yeniden başlatmayı beş dakika sonrasına planlar ve oturum açmış kullanıcılara bir mesaj gönderir. sudo shutdown -c komutu bu işlemi iptal eder. Makine geri geldiğinde her iki durumu da doğrulayın:

uname -r
sudo canonical-livepatch status

uname -r komutu artık daha yeni olan kerneli bildirmeli ve durum çıktısı yeni serinin kapsandığını göstermelidir. Makine hiçbir şekilde geri gelmezse, hata neredeyse her zaman ağda değil boot yolundadır; kurtarma yolu kernel güncellemesi sonrası açılmayan bir VPS için kılavuz içerisinde belirtilmiştir.

Eski çekirdeklerin neden temizlenmesi gerekir

Canlı yamalama (live patching), yeniden başlatma baskısını ortadan kaldırdığı ve bu sırada linux-image paketleri yüklenmeye devam ettiği için bu sorunu hafifletmek yerine daha da kötüleştirir. Her çekirdek bir önyükleme görüntüsü, bir initramfs, bir modül ağacı ve genellikle bir başlık paketi yükler. Birkaç yüz megabaytlık ayrı bir /boot bölümüne sahip küçük bir VPS üzerinde, bunlardan üç veya dört tanesi bölümü doldurur.

Tamamen dolmuş bir /boot, bir sonraki çekirdek kurulumunu bozar; bir makine ihtiyaç duyduğu güncellemeyi bu şekilde alamaz hale gelir. apt autoremove yolu, uygun olduklarında eski çekirdekleri temizler ancak hiç yeniden başlatılmayan bir makinede, paket yöneticisi hala çalışıyor olabileceğiniz bir çekirdeği emekliye ayırmayacağı için bu çekirdekler her zaman uygun durumda olmaz.

Bu nedenle, nelerin yüklü olduğunu kontrol edin, çalışan çekirdeği ve bilinen iyi bir yedek çekirdeği tutun, geri kalanını ise Ubuntu üzerinde eski çekirdekleri kaldırmak için güvenli prosedür kullanarak kaldırın. uname -r komutunun o an raporladığı çekirdeği asla kaldırmayın.

FAQ

Canlı çekirdek yamalaması, VPS'imi hiçbir zaman yeniden başlatmam gerekmeyeceği anlamına mı gelir?

Hayır. Canlı yamalar çalışan çekirdeğe yüklenir ve önyükleme imajına yazılmaz; bu nedenle disk üzerindeki linux-image, önyükleme yaptığınız sürümde kalmaya devam eder. Canonical bunu doğrudan belirtir: Livepatch "yeniden başlatmanın bir alternatifi değildir. Planlanmamış yeniden başlatmaları önleyerek size daha fazla kontrol sağlayan bir araçtır." Kapsam, çekirdek seriniz kullanımdan kaldırıldığında sona erer ve orta dereceli çekirdek düzeltmeleri hiçbir zaman canlı olarak yamalanmaz. Zorunlu bir yeniden başlatmayı beklemek yerine, kendi belirlediğiniz bir düzende bakım amaçlı yeniden başlatma planlayın.

Canlı çekirdek yamalamasının gerçekten yama uygulayıp uygulamadığını nasıl kontrol ederim?

sudo canonical-livepatch status komutunu çalıştırın ve iki satırı okuyun. kernel state, çalışan çekirdek serinizin hizmet tarafından kapsanıp kapsanmadığını bildirir; patch state ise o çekirdek için yamaların yüklü olup olmadığını raporlar. Ayrıca, yüklü her yama için bir dizin listeleyen ls /sys/kernel/livepatch/ komutu ile çekirdek tarafını doğrudan kontrol edebilirsiniz. Boş bir liste, istemci ne derse desin şu anda bellekte hiçbir şeyin yamalanmadığı anlamına gelir.

Ubuntu Pro kişisel bir VPS üzerinde ücretsiz mi?

Evet, belgelenmiş bir sınır dahilinde. Canonical'ın ifadesiyle Ubuntu Pro, Ağustos 2026 itibarıyla "5 fiziksel makineye kadar kişisel kullanım için ücretsizdir ve her zaman ücretsiz kalacaktır"; bu sayı resmi Ubuntu Topluluğu üyeleri için 50 makineye kadar çıkmaktadır. Ticari kullanım için ücretli abonelik gereklidir. Bir makineyi, Ubuntu Pro hesap sayfanızdan aldığınız bir token ile sudo pro attach TOKEN kullanarak bağlar ve ardından sudo pro enable livepatch ile hizmeti etkinleştirirsiniz.

Livepatch çalıştıktan sonra bir çekirdek CVE'si neden hala düzeltilmemiş olarak listeleniyor?

Genellikle iki nedenden biri söz konusudur. Düzeltme, önem derecesi eşiğinin altında kalmış olabilir; çünkü Canonical yalnızca "kritik ve yüksek Common Vulnerability Scoring System (CVSS) puanına ve Ubuntu Öncelik derecelendirmesine sahip çekirdek açıklarını" canlı olarak yamalar, geri kalanını diskteki pakete bırakır. Ya da düzeltme, bir fonksiyon gövdesinde değişiklik olarak ifade edilemiyor olabilir; örneğin, yukarı akış (upstream) bir veri yapısını değiştirdiğinde, canlı yamalama halihazırda tahsis edilmiş nesneler üzerinde bunu güvenli bir şekilde yapamaz. Her iki durum da aynı şekilde çözülür: güncellenmiş çekirdek paketini kurun ve bu çekirdek ile sistemi yeniden başlatın.

Canlı çekirdek yamalaması neleri hiç kapsamaz?

Kullanıcı alanı (userspace). Canonical, Livepatch'in "OpenSSL veya glibc gibi kullanıcı alanı kütüphanelerini yamalamadığını, çünkü bunun unattended-upgrades veya bir sistem yönetim aracının sorumluluğunda olduğunu" açıkça belirtir. Ayrıca, yalnızca halihazırda çalıştırdığınız seri içindeki fonksiyon gövdelerini değiştirdiği için yeni bir çekirdek sürümü veya yeni bir özellik sunamaz. Ek olarak, sunucu açıldığında çoktan çalışmış ve bellekten serbest bırakılmış olan __init fonksiyonlarını da yamalayamaz.