Inode memoizasyon cache'i eBPF güvenlik ajanının kernel CPU maliyetini ~%90 azaltıyor

Kararı yeniden yürümek yerine cache'lemek

Açık kaynak bir eBPF güvenlik ajanının geliştiricileri, politika sorgularına bir memoizasyon cache'i eklemenin dosya açma işlemlerinin kernel CPU maliyetini yaklaşık %90 azalttığını bildiriyor. Hacker News'in ana sayfasına ulaşan, nathannavein.dev blogundaki bir yazıda yazar, profillemenin gösterdiğini anlatıyor: ajanın işindeki pahalı kısım nihai izin ver veya reddet kararı değil, yol (path) tabanlı politikalardan hangisinin belirli bir dosyaya uygulandığını tespit etmektir.

Ajan dosya sistemi yolları olarak ifade edilen politikaları uygular. Her dosya açmada tetiklenen bir Linux Security Module hook'una bağlanır, dosyanın yolunu yeniden oluşturur ve sonuçları tek bir kararda birleştirmeden önce eşleşen bir kural için her seviyeyi kontrol ederek üst dizin girdileri zincirinde yukarı çıkar. Bu yürüyüş, ajanın daha önce karar verdiği dosyalar için bile her açmada tekrarlanır; bu da aynı dizinler altında dosyaları sürekli yeniden açan veritabanı gibi iş yüklerini olumsuz etkiler.

Cache'in anahtarını inode'lara bağlamak

Ekip cache'i dentry'lerle anahtarlamayı düşündü ama bunu elendi: dentry'ler işaretçilerdir ve eBPF map'lerinde saklanamazlar; içeriklerini bir struct'a kopyalamak ise ağır bir anahtar oluştururdu. Bunun yerine cache, iki ek alanla nitelendirilen inode numarasıyla anahtarlanıyor: mount ID ve mount namespace ID. Inode numaraları yalnızca belirli bir mount ağacı içinde benzersizdir; bu yüzden mount ID, farklı mount'lardaki çakışan inode numaralarını ayırt ederken, namespace bileşeni bir namespace'te cache'lenen kararın başka birinde yeniden kullanılmasını engeller.

Cache'lenen değer küçük kalıyor: ajanın bitmask ile kodlanmış politika tablosundaki bir bit konumunu gösteren bir erişim indeksi ve "eşleşen politika yok" ya da "global salt okunur" gibi durumları ayırt eden bir durum baytı. Her şey 10.000 girdiyle sınırlı bir LRU hash map'te tutuluyor. Bir isabet, ajanın doğrudan cache'lenen sonuçtan harekete geçmesini sağlıyor; bir ıskalama ise tam yol yürüyüşünü tetikliyor ve sonucu bir dahaki sefere saklanıyor.

Ölçülen iyileşme

Yazarın benchmark'ında aynı dosyayı 200.000 kez açmak, cache olmadan 28 milyar, cache ile 3,03 milyar kernel CPU döngüsü tüketmiş; ölçüm perf'in cycles:k olayıyla yapılmış. Değişiklikten önceki flamegraph'lar, ajanın kendi fonksiyonlarının profili domine ettiğini gösteriyordu: tail_call_security_check örneklerin %89,2'sinde, is_restricted_filepath %81,9'unda ve path_check_callback %63,7'sinde stack'te görünüyordu. Sonrasında ikincisi kabaca %0,02'ye geriledi ve bir dosyanın ilk sorgusu cache'lendikten sonra fiilen kayboldu.

Hardlink'ler muhafazakâr bir geri dönüşü zorunlu kılıyor

Bir doğruluk riski daha var: birden çok yol tek bir inode'ya işaret edebilir, bunun bariz örneği hardlink'lerdir; dolayısıyla bir yoldan türetilen cache'lenmiş politika başka bir yol için yanlış olabilir. Yazarlar bunu, inode'nun link sayısını okuyarak ve birden büyük olduğunda cache'i tamamen atlayarak çözüyor ve tam yol yürüyüşüne geri dönüyorlar. Yazar bunu gerçek bir çözüm değil bir geçici çözüm olarak nitelendiriyor; yanlış cache'lenmiş bir cevabın, yavaş ama doğru olandan daha kötü olduğu gerekçesiyle doğruluk karşılığında azaltılmış cache kapsamını kabul ediyor.

Neden önemli

LSM hook'larına binen güvenlik ajanları bir makinedeki her dosya açmada çalışır; dolayısıyla ek yükleri tüm sisteme uygulanan bir vergi gibi davranır ve eBPF tabanlı uygulamanın benimsenmesinin bilinen bir engelidir. Bu sonuç, söz konusu verginin büyük kısmının uygulamanın kendisinden değil gereksiz sorgu işinden gelebileceğini ve mount namespace, mount ve inode üzerinden anahtarlanmış mütevazı bir LRU map'in bunu ortadan kaldırabileceğini gösteriyor. Cache tamamen dahilidir; yani dağıtımlar tek bir politika kuralına dokunmadan hızlanmanın tadını çıkarır. Bu teknik, eBPF LSM araçları geliştiren herkes için tekrarlanabilir bir desendir ve yazarlar ajanı GitHub'da bomfather/agent olarak açık kaynakladıkları için uygulama ve benchmark'lar doğrudan incelenebilir ve yeniden çalıştırılabilir.