Canlı çekirdek yamalama mı yoksa VPS yeniden başlatma mı?

Canlı çekirdek yamalamanın VPS üzerindeki işlevi

Canlı çekirdek yamalama, ç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 tüm çağrılar 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 başlatılmış durumdadır ve bu yamaların her biri yalnızca bellekte yaşar.

Canlı yamalama genellikle yönetilen bir planın özelliği olarak pazarlanır. Yönetilmeyen bir sunucuda ise bunu iki komutla kendiniz etkinleştirebilirsiniz; bu durum, yönetilen ve yönetilmeyen 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 kullanılarak gerçekleştirilir. Çoğu çekirdek fonksiyonu, argümanlara veya yığına (stack) dokunulmadan önce, fonksiyonun en başında bir çağrı talimatı ile 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, bir fonksiyonun içindeki tek bir satır değil, fonksiyonun tamamıdır.

Daha zor olan kısım, canlı bir sistemi güvenli bir şekilde değiştirmektir. Fonksiyonu değiştirdiğiniz sırada bazı CPU'ların yığınında eski kod çalışıyorsa, 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 geçiş yapana kadar yama geçiş aşamasındadır.

Sonucu kendiniz görebilirsiniz. Uygulanan yamalar /sys/kernel/livepatch altında, her yama için bir dizin olacak şekilde 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 kurulmuş bir sunucuda normal başlangıç durumudur.

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

Fonksiyon gövdeleri yamalanır. Bunun dışındaki hiçbir şey yamalanmaz.

• Değiştirilmiş veri yapıları. Eğer yukarı yönlü (upstream) düzeltme bir yapıya (struct) yeni bir alan ekliyorsa veya mevcut bir alanın anlamını değiştiriyorsa, 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ı değiştiren bir düzeltmenin, tüm fonksiyonların aynı anda değişmesini gerektirmesi gerekir; tutarlılık modeli, 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 çoktan çalışmış ve bellekten serbest bırakılmıştır; bu nedenle yönlendirilecek bir şey kalmamıştır.
• Yeni çekirdek sürümleri ve yeni özellikler. Canlı yamalama, sizi tek bir çekirdek serisi içinde bir yama seviyesinden diğerine taşır. Sizi asla bir seriden diğerine geçirmez ve asla yeni bir özellik eklemez. Eğer Linux 7.1 ile gelen değişiklikler gibi daha yeni bir seriden bir şey istiyorsanız, o çekirdeği kurar ve sistemi onunla başlatırsınız.
• Kullanıcı alanı (Userspace). Canonical sınırı şu ş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'in yanındaki canlı yamalı bir çekirdek, yamalı bir sunucu anlamına gelmez; bu nedenle kullanıcı alanı paketlerini yöneten unattended upgrades aracını aynı sunucuda tutmaya devam edin.

Ubuntu'nun hizmetinde bir önem derecesi sınırı da mevcuttur. Canonical, "çekirdek güvenlik açıklarını, kritik ve yüksek Common Vulnerability Scoring System (CVSS) puanları ve Ubuntu Öncelik derecelendirmeleri ile 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, diskteki pakette düzeltilir ve canlı yamalanmaz; bu nedenle çalışan çekirdeğinize bir sonraki yeniden başlatmada ulaşır, daha erken değil.

Canlı çekirdek yamalama seçenekleri nelerdir?

Yaygın olarak kullanılan üç farklı yaklaşım mevcuttur ve bunların tamamı 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 ifadesine göre bu hizmet "kişisel kullanımda 5 fiziksel makineye kadar ü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 için ücretli abonelik gereklidir. Kapsam, çekirdek serisi ve sürüm türü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üm türleri genelinde kapsar. Bir sisteme 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 üretici betiği olan curl -s -L https://kernelcare.com/installer | bash ile başlar, ardından anahtar tabanlı lisanslama için /usr/bin/kcarectl --register KEY kullanılır. 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 doğrudan bir kabuğa yönlendirmeden önce yükleyici betiğini mutlaka okuyun.

kpatch ve kGraft bu teknolojilerin öncüleridir. kGraft SUSE'den, kpatch ise Red Hat'ten gelmiştir ve günümüzde ana hat (upstream) Linux çekirdeğindeki canlı yamalama çekirdeği, her iki fikrin birleşimidir. kpatch projesi sona ermektedir: README dosyasında Linux 6.19 sürümünden itibaren "kpatch projesinin kullanımdan kaldırıldığı ve bakım moduna alındığı" belirtilmekte olup, kpatch-build yerini ana hat çekirdekte klp-build bileşenine bırakmaktadır. RHEL ve türevlerinde, yamaları elle oluşturmak yerine dağıtımın kendi sunduğu servisi kullanmanız önerilir.

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 olmadan ç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 buna Livepatch de dahildir. 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ı detayları 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 çekirdekle önyükleme yaptığınızda bu satır hata verir. patch state ise o çekirdeğe uygulanacak yamaların gerçekten 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 artık belirgin değildir. Bunu ayrıca kontrol etmeniz gerekir.

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

Bir paket yüklendiğinde etkinleşmesi için yeniden başlatma gerekiyorsa paket yöneticisi /var/run/reboot-required dosyasını oluşturur; yeni bir linux-image paketi yüklendiğinde ise bu dosya her zaman oluşturulur. .pkgs dosyası, hangi paketlerin yeniden başlatma talep ettiğini listeler. İlk komut No such file or directory yanıtını verirse, makine son açıldığından beri 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), bu nedenle her iki yol da aynı dosyaya ulaşır.

Bu işaretleyici 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 sürümünün bulunması, Livepatch durumu ne olursa olsun makinenin eski bir çekirdek üzerinde çalıştığı anlamına gelir. Önemli olan kontrol budur; çünkü canlı yamalama, çalışan çekirdeği güvenli hale getirmek için tasarlanmıştır, onu güncel tutmak için değil.

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

sudo needrestart -r l

-r l işaretleyici çifti "yalnızca listele" anlamına gelir, bu nedenle hiçbir şeyi değiştirmez, sadece raporlar.

Yeniden başlatma gereksinimi neden hiç bitmez

Disk üzerindeki kernel değişmez. Live patch'ler çalışan kernel'a yüklenir ve hiçbir zaman boot imajına yazılmaz; bu nedenle yeniden başlatma işlemi, bootloader'ın seçtiği linux-image üzerinde sistemin açılmasına neden olur ve Livepatch istemcisi, geçerliliğini koruyan yamaları tekrar uygular. Bu iki an arasında yamalanmamış kod çalıştırırsınız; bu da eski bir kernel yerine güncel bir kernel ile boot etmek 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 hattı kapsam raporlamayı durdurur ve tek çözüm daha yeni bir kernel kullanmaktır. Bu da bir yeniden başlatma demektir. LTS sürümlerinde yeni seri genellikle 26.04.1 gibi bir ara sürüm içerisinde donanım etkinleştirme (HWE) kerneli olarak size ulaşır; dolayısıyla değişim zaten arşivde beklemektedir, eksik olan tek şey sizin planlayacağınız bir boot işlemidir.

Orta ve düşük önem derecesindeki kernel düzeltmeleri asla live patch ile uygulanmaz. Bunlar diskteki pakette bekler ve yalnızca boot ettiğinizde size ulaşır.

Uzun süre çalışan kernel'lar, yama ile temizlenemeyen durumlar da biriktirir. Canonical'ın kendi duruşu, dürüst 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. Zamanını siz seçersiniz.

Yeniden başlatma sonrası erişilebilirliği sağlama

Konsola erişemiyorsanız, 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. Tamamen dolu bir /boot, kernel paketi initramfs (initial RAM filesystem) yazarken 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ışan eski kernel sürümünü sistemde tutun. GRUB bunu "Advanced options for Ubuntu" altında listeler; yeni bir kernel başarısız olduğunda, eski 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ı konsolda bir initramfs istemi görünüyorsa, onarım burada yapılır.

Ardından, uyanık olduğunuz bir zamanda yeniden başlatma 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 artık daha yeni olan kerneli bildirmeli ve durum çıktısı yeni serinin kapsandığını göstermelidir. Eğer makine hiç geri gelmezse, hata neredeyse her zaman ağda değil, önyükleme yolundadır; kurtarma yolu kernel güncellemesi sonrası açılmayan VPS için kılavuz içerisinde belirtilmiştir.

Eski çekirdeklerin neden temizlenmesi gerekir

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 yüzden alamaz hale gelir. apt autoremove yolu, uygun olduklarında eski çekirdekleri temizler; ancak hiç yeniden başlatılmayan bir sunucuda, paket yöneticisi hala çalışıyor olabileceğiniz bir çekirdeği emekliye ayırmayacağı için bu çekirdekler her zaman temizlenmeye uygun 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 yamalama işlemi, VPS sunucumu 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 emekli edildiğinde sona erer ve orta şiddetli çekirdek düzeltmeleri hiçbir zaman canlı yamalanmaz. Zorunlu bir yeniden başlatmayı beklemek yerine, kendi belirlediğiniz bir periyotta bakım amaçlı yeniden başlatma planlayın.

Canlı çekirdek yamalamanı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 servis 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 ifadesine göre 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 ücretli abonelik gerektirir. Bir makineyi, Ubuntu Pro hesap sayfanızdan aldığınız bir token ile sudo pro attach TOKEN kullanarak bağlayın ve ardından sudo pro enable livepatch ile servisi etkinleştirin.

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ı yamalar ve 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 bunu halihazırda tahsis edilmiş nesneler üzerinde güvenli bir şekilde yapamaz. Her iki durum da aynı şekilde çözülür: güncellenmiş çekirdek paketini kurun ve bu çekirdek ile önyükleme yapın.

Canlı çekirdek yamalama neleri 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ığı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 ayağa kalktığında çoktan çalışmış ve bellekten silinmiş olan __init fonksiyonlarını da yamalayamaz.