VPS uzerinde AES-NI aktif mi? Kontrol ve etkinlestirme

Bir VPS üzerinde AES-NI size gerçekte ne kazandırır

Bir VPS üzerindeki AES-NI, donanım seviyesinde AES (gelişmiş şifreleme standardı) işleminin bir turunu gerçekleştiren altı adet x86 komut setidir. Sağlayıcınızın CPU modeli bu komutları gizlese bile, altındaki silikon bu komutlara sahiptir; ancak OpenSSL bunları göremez ve bayt başına yaklaşık on kat daha fazla döngü maliyeti olan bir yazılım uygulamasına geri döner. Bu özelliği tek bir komutla kontrol edebilir, aradaki farkı iki komutla ölçebilir ve genellikle tek bir ortam değişkeni ile hızlı yolu tekrar zorlayabilirsiniz.

Bu komutlar AESENC, AESENCLAST, AESDEC, AESDECLAST, AESIMC ve AESKEYGENASSIST şeklindedir. Intel bunları 2010 yılında piyasaya sürmüş, AMD de bunu takip etmiştir; bu nedenle kiralayacağınız herhangi bir sunucu CPU'su bu silikona sahiptir. Tamamlayıcı bir komut olan PCLMULQDQ, GCM'in (Galois/sayaç modu) kimlik doğrulama etiketini oluşturmak için ihtiyaç duyduğu taşımasız çarpma işlemini gerçekleştirir. AES-GCM yalnızca her ikisi de mevcut olduğunda hızlıdır, çünkü şifreleyici ve etiket ayrı iş parçalarıdır.

Bir VPS üzerinde bunun izleme kayıtlarınızda göründüğü dört yer:

• TLS (taşıma katmanı güvenliği) sonlandırma. AES-128-GCM veya AES-256-GCM sunan bir web sunucusu, toplu kripto işlemlerinin çoğunu AES içinde harcar.
• Şifreli birimler. LUKS (Linux birleşik anahtar kurulumu) ve dm-crypt, çekirdek içinde ve CPU üzerinde her okuma ve yazma işleminde aes-xts çalıştırır.
• AES tabanlı VPN trafiği. AES-256-GCM kullanan OpenVPN ve AES-GCM kullanan IPsec'in her ikisi de buna dayanır.
• Şifreli yedeklemeler. Bir akışı sunucudan çıkmadan önce AES ile şifreleyen her şey aynı maliyeti öder.

Yaygın bir iş yükü bundan hiç etkilenmez. WireGuard, verileri için ChaCha20-Poly1305 kullanır ve AES'e asla dokunmaz; bu nedenle kendi kendine barındırılan WireGuard VPN, bayrağın maskelendiği bir ana makinede aynı hızda çalışır. Bu fark, ucuz bir VPS için bir tünel seçmeden önce WireGuard ile OpenVPN'i karşılaştırmak için pratik bir nedendir.

VPS sunucunuzun AES-NI desteğine sahip olup olmadığını kontrol etme

Çekirdek, CPUID özellik bitlerini /proc/cpuinfo dosyasına kopyalar, bu nedenle tek bir grep komutu soruyu yanıtlar.

grep -m1 -o '\baes\b' /proc/cpuinfo
lscpu | grep -i -o '\baes\b'

Komutlardan herhangi birinin aes çıktısını vermesi, CPU'nun bu konuğa AES-NI desteğini bildirdiği anlamına gelir. Hiçbir çıktı alınmaması, desteğin olmadığını gösterir. lscpu aynı bayrakları okur, bu nedenle iki komut her zaman aynı sonucu verir. Hangisi yüklüyse onu kullanın.

Şimdi ana makinenin (host) sizi hangi CPU üzerinde çalıştırdığını belirttiğine bakın.

grep -m1 'model name' /proc/cpuinfo

Intel(R) Xeon(R) Gold 6338 CPU @ 2.00GHz veya AMD EPYC 7443P 24-Core Processor gibi gerçek bir model dizisi, ana makinenin fiziksel CPU modelini size doğrudan aktardığı anlamına gelir. QEMU Virtual CPU version 2.5+ veya Common KVM processor çıktısı ise başka bir durumun söz konusu olduğunu gösterir; bu durum, üzerinde durulması gereken bir konudur.

Silikon desteklemesine rağmen bayrağın eksik görünmesinin nedeni

CPUID, bir programın CPU'ya neleri desteklediğini sormak için kullandığı talimattır. Sanal makine içerisinde CPUID her zaman hipervizöre (hypervisor) takılır, bu nedenle konuk sisteme ne söyleneceğine hipervizör karar verir. Çoğu panel, bu kararı bir konuk CPU modeli olarak sunar. qemu64 ve kvm64 genel temel modellerdir ve hiçbiri özellik setinde AES-NI veya SSSE3 içermez; bu yüzden fiziksel ana makine güncel bir EPYC olsa bile konuk sistem hiçbir aes bayrağı görmez. VPS, başkasının donanımı üzerinde çalışan bir konuk sistemdir, dolayısıyla raporladığı her özellik bir üst seviyede verilmiş bir karardır. Bu katmanlama yapısı sizin için yeniyse, VPS nedir konusundan başlayın.

Ana makineler genel bir modeli kasıtlı olarak seçer; çünkü farklı işlemcilere sahip makineler arasında canlı taşıma (live migration), yalnızca konuk sisteme hedef makinede bulunmayan bir özellikten hiç bahsedilmediği sürece çalışır. Bunun maliyeti size yansır. Çekirdeğiniz ve OpenSSL kopyanız, maskelenmiş CPUID'yi başlangıçta bir kez okur ve ardından sürecin ömrü boyunca yavaş olan kod yolunu seçer.

Kaynaktaki çözüm bir ana makine tarafı ayarıdır: QEMU terimleriyle -cpu host, AES-NI içeren adlandırılmış bir model veya modele açıkça eklenmiş bir +aes. Bunların hiçbirini konuk sistemin içinden ayarlayamazsınız. Bir destek talebi açmak veya hipervizörü CPU modelini doğrudan geçiren (passthrough) bir plan seçmek kalıcı çözümdür.

openssl speed ile farkı ölçün

Yayınlanmış bir benchmark sonucuna körü körüne güvenmeyin. Kendi sunucunuzun fiilen kullandığı şifreleme algoritmasını çalıştırın.

openssl version
openssl speed -evp aes-128-gcm

Sonuç satırı AES-128-GCM olarak etiketlenmiştir ve saniyede 1000 bayt biriminden, altı farklı blok boyutu için iş hacmini verir. Toplu veri aktarımı için 8192 baytlık sütunu okuyun; çünkü 16 baytlık sütun çağrı başına düşen ek yükten etkilenir ve dosya indirme performansı hakkında bilgi vermez.

Şimdi aynı komutu, yazılım tarafında AES-NI ve PCLMULQDQ devre dışı bırakılmış şekilde çalıştırın:

OPENSSL_ia32cap="~0x200000200000000" openssl speed -evp aes-128-gcm

Bu değer, OpenSSL'in kendi yetenek vektörü dokümantasyonundan gelir. Başındaki ~ ifadesi "bu bitleri temizle" anlamına gelir. 57. bit AES-NI, 33. bit ise PCLMULQDQ değeridir; dolayısıyla 0x200000200000000 tam olarak bu ikisini hedefler ve başka hiçbir şeye dokunmaz. İkinci sayının ilk sayıdan çok daha düşük olması, sunucunuzda AES-NI desteğinin çalıştığını ve işlemin tamamlandığını gösterir. Birbirine eşit iki sayı, OpenSSL'in zaten yazılım yolunu kullandığını gösterir; çünkü temizlenecek bir bayrak zaten mevcut değildir.

[
  {
    "label": "AES-NI and PCLMULQDQ",
    "mb_per_sec": "4,850",
    "cycles_per_byte": 0.7
  },
  {
    "label": "Software fallback",
    "mb_per_sec": 310,
    "cycles_per_byte": 11.0
  }
]

Bunlar, 3.4 GHz civarındaki modern bir x86 çekirdeği için yayınlanmış temsili rakamlardır, herhangi bir sunucudan alınmış ölçümler değildir. Bunları bir eğilim olarak değerlendirin. Donanım yolu bayt başına yaklaşık 0.7 döngüde, yazılım yedeği ise yaklaşık 11.0 döngüde çalışır; bu da tek bir çekirdek üzerinde yaklaşık 4,850 MB/s'ye karşı 310 MB/s değerine denk gelir. Yukarıdaki iki komutunuz, sunucunuzu tanımlayan tek gerçek veriyi üretir. Aynı disiplin makinenin geri kalanı için de geçerlidir; bu nedenle bir plan hakkında sonuca varmadan önce bunu tekrarlanabilir bir VPS benchmark yöntemi ile birlikte kullanın.

OPENSSL_ia32cap ile bitleri zorla etkinleştirme

Bu kısım insanları şaşırtan bölümdür. AES-NI komutları ayrıcalıksızdır ve hipervizör bunları yakalamaz. Yalnızca CPUID yakalanır. Bu nedenle bir ana makine, konuk sisteminize AES-NI'nin mevcut olmadığını söyleyebilir ancak AESENC yerel olarak tam hızda çalışmaya devam eder. Yazılım, CPUID'ye sorduğu ve yanlış bir yanıt aldığı için hızlı yolu atlar. Komutun kendisi hiçbir zaman çalışmayı durdurmamıştır.

OpenSSL, CPU adına yanıt vermenize olanak tanır. OPENSSL_ia32cap içindeki düz bir onaltılık değer, yetenek vektörünü maskelemek yerine üzerine yazar.

OPENSSL_ia32cap="0x0200020207000000" openssl speed -evp aes-128-gcm

Eğer bu çalıştırma, normal çalıştırmadan birkaç kat daha hızlıysa, donanım AES-NI'ye sahiptir ve ana makineniz bunu gizliyordur. Bu öncelikle bir tanılamadır. OpenSSL için bu aynı zamanda bir düzeltmedir.

İki uyarı geçerlidir ve her ikisini de bilerek tetikleyebilirsiniz.

Yalnızca ilk vektörü ayarlamak, sonraki vektörleri sıfırda bırakır; bu da AVX2 ve AVX-512 kod yollarını kapatır. Bu burada kasıtlıdır. Maskelenmiş bir konuk sistemde AVX bitlerini zorla açmaya çalışmayın, çünkü AVX kayıtları işletim sisteminin XCR0 içindeki genişletilmiş durumu etkinleştirmesini gerektirir ve çekirdeğiniz aynı maskelenmiş CPUID'ye dayanarak bunu reddetmiştir. VEX kodlu bir komut daha sonra tanımsız işlem kodu hatası (undefined-opcode fault) verir ve süreç sonlanır.

AES-NI'nin gerçekten bulunmadığı bir çekirdekte bunu zorlamak, süreci anında öldürür:

Illegal instruction (core dumped)

Bu, AESENC'nin tanımsız işlem kodu hatası vermesidir, çünkü o çekirdekte yürütülecek böyle bir komut yoktur. Bazı sunucu aygıt yazılımları da bir sonraki sıfırlamaya kadar AES-NI'yi donanım düzeyinde devre dışı bırakabilir ve belirti aynıdır. Her iki durumda da çözüm farklı bir ana makinedir, farklı bir ortam değişkeni değil.

Uzun süre çalışan bir servis için geçersiz kılma ayarını korumak istiyorsanız, bir systemd drop-in dosyası kullanın.

sudo systemctl edit nginx

[Service]
Environment="OPENSSL_ia32cap=0x0200020207000000"

sudo systemctl daemon-reload
sudo systemctl restart nginx
sudo systemctl show nginx -p Environment

Son komut, değişkeni size geri yazdırmalıdır. Ne yaptığınızı anladığınızdan emin olun: Eğer sunucu, CPU'su gerçekten AES-NI'den yoksun bir ana makineye taşınırsa, nginx ilk TLS bağlantısında geçersiz komut hatasıyla (illegal instruction) çöker. Bunu operasyonel el kitabınıza (runbook) ekleyin veya geçersiz kılma ayarını üretim ortamından tamamen uzak tutun ve yalnızca bir destek talebi açarken durumu kanıtlamak için kullanın.

Geçersiz kılma işleminin düzeltemediği durumlar

OPENSSL_ia32cap yalnızca OpenSSL'e ulaşır, başka hiçbir yere etki etmez. Diğer tüm yazılımlar kendi özellik algılama mekanizmalarını çalıştırır ve bu değişkeni asla okumaz.

Çekirdek (kernel) önemli bir örnektir. dm-crypt ve LUKS, çekirdek kripto API'sini kullanır ve CPU özellik biti eksik olduğunda aesni_intel modülü yüklenmeyi reddeder:

modprobe: ERROR: could not insert 'aesni_intel': No such device

Bunun için kullanıcı alanında (user-space) bir değişken yoktur. Çekirdek, CPUID'yi önyükleme sırasında bir kez okur ve bu karar farklı bir ana makinede yeniden başlatma yapana kadar geçerli kalır; dolayısıyla OpenSSL ne yaparsa yapsın şifrelenmiş biriminiz yazılımsal şifreleme (software cipher) üzerinde kalmaya devam eder. Gerçekte ne elde ettiğinizi ölçün:

sudo cryptsetup benchmark -c aes-xts -s 256

aes-xts 256b satırı, donanımsal AES ile saniyede binlerce MiB hıza ulaşırken, donanımsal destek olmadığında bu hız yüzlü MiB/s seviyelerine düşer. Go ve Java dahil olmak üzere kendi algılama mekanizmalarına sahip dil çalışma zamanları (runtime) da aynı şekilde bu değişkenin kapsamı dışındadır. Go'nun crypto/aes bileşeni doğrudan CPUID'yi kontrol eder ve özellik biti kapalı olduğunda sessizce sabit zamanlı yazılımsal uygulamasını kullanır. TLS trafiğinizi sonlandıran servis bir Go ikili dosyasıysa, OpenSSL değişkeni onun için hiçbir şeyi değiştirmez.

AES-NI kullanamıyorsanız ChaCha20 tercih edin

ChaCha20-Poly1305, yazılım tabanlı işlemlerde hızlı çalışacak şekilde tasarlanmıştır. Kullanılabilir bir AES-NI birimi olmayan işlemcilerde genellikle AES-GCM'den çok daha yüksek performans gösterir; bu nedenle böyle bir sunucuda AES tercihini bırakmak mantıklı bir adımdır.

OpenSSL 1.1.1 veya daha yeni bir sürümle derlenmiş nginx 1.19.4 ve sonraki sürümler için:

ssl_prefer_server_ciphers on;
ssl_ciphers ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
ssl_conf_command Ciphersuites TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384;

ssl_ciphers, TLS 1.2 protokolünü kapsar. ssl_conf_command Ciphersuites ise TLS 1.3 protokolünü kapsar; nginx bu protokol için özel bir yönergeye sahip değildir ve dizgiyi kontrol etmeden doğrudan OpenSSL'e iletir, bu nedenle yapılan bir yazım hatası sessizce kabul edilir. Yapılandırmayı yeniden yükleyin ve istemciye nelerin sunulduğunu doğrulayın:

sudo nginx -t && sudo systemctl reload nginx
openssl s_client -connect example.com:443 -tls1_3 </dev/null 2>/dev/null | grep -i cipher

Sağlıklı bir sonuç TLS_CHACHA20_POLY1305_SHA256 ifadesini içermelidir. Değişikliği kalıcı hale getirmeden önce, aynı sunucuda AES testiyle birlikte openssl speed -evp chacha20-poly1305 komutunu çalıştırın ve elde ettiğiniz iki değeri karşılaştırarak karar verin.

ARM sunucular farklı uzantılar kullanır

AES-NI yalnızca x86 mimarisine özgüdür. Bir ARM VPS, aynı işlevi gören ayrı bir komut seti olan ARMv8 kriptografik uzantılarını kullanır. aarch64 mimarisinde bayraklar flags yerine Features altında bulunur:

grep -m1 Features /proc/cpuinfo

aes ve pmull ifadelerini arayın. pmull, PCLMULQDQ karşılığı olan ARM komutudur ve GCM aynı nedenle buna ihtiyaç duyar. OpenSSL'in ARM üzerindeki geçersiz kılma değişkeni OPENSSL_armcap'tir ve OpenSSL kaynak kodundaki crypto/arm_arch.h içinde tanımlanan kendine has bir bit düzenine sahiptir; bu nedenle bu kılavuzdaki x86 onaltılık (hex) değeri orada bir anlam ifade etmez. Uygulamada, VPS sunucusu olarak satılan ARM sunucu çekirdekleri bu uzantıları dışa aktarır, bu yüzden maskelenmiş özellik sorunu büyük ölçüde x86 mimarisine özgü bir durumdur.

Hata modları ve karşılaşacağınız dizgeler

/proc/cpuinfo içinde aes yok ve zorunlu çalıştırma çok daha hızlı. Ana makine CPUID'yi maskeliyor. Model adının genel (generic) olduğunu doğrulayın, ardından sağlayıcınıza hipervizörlerinin konuk CPU modeli olarak ne sunduğunu sorun.

/proc/cpuinfo içinde aes yok ve zorunlu çalıştırma Illegal instruction çıktısı veriyor. Talimatlar gerçekten mevcut değil veya aygıt yazılımı (firmware) bunları devre dışı bırakmış. İş yükünü farklı bir ana makineye taşıyın.

aes mevcut ancak iş hacmi (throughput) hâlâ düşük. 8192 baytlık sütunu okuduğunuzdan ve çekirdeği başka hiçbir şeyin kullanmadığından emin olun. Paylaşımlı bir planda, gürültülü bir komşu (noisy neighbour), testi günün farklı saatlerinde iki kez çalıştırana kadar eksik bir CPU özelliği gibi görünür.

Maskelenmiş çalıştırma ve normal çalıştırma aynı sonucu veriyor. OpenSSL zaten yazılım yolundaydı. Bu sonuç bir test hatası değil, bulgunun kendisidir.

İç içe sanallaştırma (nested virtualisation) cevabı bir seviye aşağıda değiştirir. Bir konuk içindeki konuk, orta katmanın aktarmayı seçtiği CPUID'yi alır ve AES-NI burada fark edilmeden kolayca kaybolabilir. Eğer bir VPS üzerinde iç içe sanal makineler çalıştırıyorsanız, bayrağı kiraladığınız makinede olduğu kadar iç konuğun içinde de kontrol edin.

FAQ

VPS sunucumda /proc/cpuinfo içerisinde neden aes bayrağı yok?

Çünkü hipervizör, genel bir konuk CPU modeli sunmaktadır. qemu64 ve kvm64, özellik setlerinde AES-NI barındırmaz; bu nedenle fiziksel işlemci ne olursa olsun CPUID bunu eksik olarak raporlar. Sunucular, çalışan bir konuğun farklı CPU'lara sahip makineler arasında taşınabilmesi için bu yöntemi kullanır. grep -m1 'model name' /proc/cpuinfo komutunu çalıştırın: QEMU Virtual CPU version 2.5+ veya Common KVM processor gibi bir dizge, sanallaştırmayı işaret eder. Gerçek bir Xeon veya EPYC model dizgesi ise CPU modelinin doğrudan aktarıldığını ve bayrağın gerçekten silikon üzerinde bulunmadığını gösterir.

OPENSSL_ia32cap gerçekten AES-NI'yi etkinleştiriyor mu, yoksa sadece taklit mi ediyor?

Gerçek komutları etkinleştirir. AES-NI komutları ayrıcalıksızdır ve hipervizör bunları asla yakalamaz; bu nedenle AESENC, CPUID ne rapor ederse etsin yerel olarak çalışır. Yalnızca CPUID komutu kesintiye uğratılır. OPENSSL_ia32cap değerini düz bir onaltılık (hexadecimal) değer olarak ayarlamak, OpenSSL'in CPUID'den aldığı yanıtı değiştirir. Böylece OpenSSL donanım kod yolunu seçer ve donanım bunu tam hızda çalıştırır. Eğer silikon gerçekten bu komutlardan yoksunsa, işlem ilk AES operasyonunda Illegal instruction (core dumped) hatasıyla sonlanır.

Bu geçersiz kılma işlemi LUKS şifreli birimimi hızlandırır mı?

Hayır. OPENSSL_ia32cap yalnızca OpenSSL tarafından okunur, başka hiçbir şey tarafından değil. LUKS ve dm-crypt, çekirdek kripto API'sini kullanır; burada özellik biti temizlendiğinde aesni_intel modülü modprobe: ERROR: could not insert 'aesni_intel': No such device hatasıyla yüklenemez. Çekirdek, CPUID'yi önyükleme sırasında okur ve hiçbir kullanıcı alanı değişkeni bunu değiştiremez. Gerçek değeri sudo cryptsetup benchmark -c aes-xts -s 256 ile ölçün ve aes-xts 256b satırını, bayrağı raporlayan bir sunucu ile karşılaştırın.

Eksik bir AES-NI bayrağı WireGuard'ı yavaşlatır mı?

Hayır. WireGuard tüm veriler için ChaCha20-Poly1305 kullanır ve hiçbir zaman AES komutlarına başvurmaz; bu nedenle verimi, maskelenmiş bir sunucuda da maskelenmemiş bir sunucuda da aynıdır. AES-GCM ile yapılandırılmış OpenVPN ve IPsec ise AES-NI olmayan bir sunucuda verim kaybı yaşar. Aynı VPS üzerindeki iki tünel bu nedenle çok farklı davranabilir; ağı suçlamadan önce bunu bilmek önemlidir.

ARM tabanlı bir VPS'te AES-NI desteğini nasıl kontrol ederim?

ARM çekirdeklerinde AES-NI bulunmaz. Bunun yerine, aynı işi farklı komutlarla yapan ARMv8 kriptografik uzantıları mevcuttur. grep -m1 Features /proc/cpuinfo komutunu çalıştırın ve aes ile pmull değerlerini arayın; zira aarch64 mimarisinde bunlar flags yerine Features altında listelenir. x86'daki OPENSSL_ia32cap değerinin ARM üzerinde bir karşılığı yoktur. OpenSSL'in oradaki eşdeğer değişkeni OPENSSL_armcap'tür ve bit düzeni OpenSSL kaynak kodundaki crypto/arm_arch.h dosyasında tanımlanmıştır.