AWS Firecracker VMM'nin Mikro Mimari Güvenliği: Arka Plan

Yazarlar: (1) Zane Weissman, Worcester Politeknik Enstitüsü Worcester, MA, ABD {zweissman@wpi.edu}; (2) Thomas Eisenbarth, Lübeck Lübeck Üniversitesi, SH, Almanya {thomas.eisenbarth@uni-luebeck.de}; (3) Thore Tiemann, Lübeck Lübeck Üniversitesi, SH, Almanya {t.tiemann@uni-luebeck.de}; (4) Berk Sunar, Worcester Politeknik Enstitüsü Worcester, MA, ABD {sunar@wpi.edu}. Bağlantı Tablosu Özet ve Giriş Arka plan Tehdit Modelleri Havai Fişek Muhafaza Sistemlerinin Analizi Firecracker Mikrovm'lerinde Mikro Mimari Saldırı ve Savunmaların Analizi Sonuç, Teşekkür ve Referanslar 2. ARKAPLAN 2.1 KVM Linux çekirdeği tabanlı sanal makine (KVM) [29], modern CPU'larda bulunan Intel VT-x veya AMD-V gibi donanım destekli sanallaştırma özelliklerinin bir özetini sağlar. Yerele yakın yürütmeyi desteklemek için, mevcut çekirdek modu ve kullanıcı moduna ek olarak Linux çekirdeğine bir konuk modu eklenir. Linux konuk modundaysa KVM, donanımın halka 0 ve halka 3 ayrıcalıklarını çoğaltan donanım sanallaştırma moduna girmesine neden olur.[1] KVM ile, G/Ç sanallaştırması, genellikle ayrı bir hipervizör süreci gerektiren önceki hipervizörlerin aksine, VMM veya hipervizör olarak adlandırılan VM'yi oluşturan süreç tarafından çoğunlukla kullanıcı alanında gerçekleştirilir [41]. Bir KVM hipervizörü, her VM konuğuna, konuğu oluşturan sürecin bellek bölgesinden ayrı olan kendi bellek bölgesini sağlar. Bu, kullanıcı alanından olduğu kadar çekirdek alanından oluşturulan konuklar için de geçerlidir. Her VM, Linux ana bilgisayarındaki bir işlemle eşleşir ve konuğa atanan her sanal CPU, o ana bilgisayar işlemindeki bir iş parçacığıdır. VM'nin kullanıcı alanı hipervizör süreci, yalnızca ayrıcalıklı yürütme gerektiğinde KVM'ye sistem çağrıları yaparak bağlam değiştirmeyi en aza indirir ve VM'yi çekirdek saldırı yüzeyine indirger. Bu tasarım, her türlü uygulamada performans iyileştirmeleri sağlamanın yanı sıra, özellikle bireysel programları korumalı alana almak ve birçok VM'nin aynı anda çalıştığı bulut ortamlarını desteklemek için yararlı olan hafif hipervizörlerin geliştirilmesine olanak tanıdı. 2.2 Sunucusuz Bulut Bilişim Bulut bilişim için giderek daha popüler hale gelen bir model, CSP'nin kullanıcının kodunu çalıştıran sunucuların ölçeklenebilirliğini ve kullanılabilirliğini yönettiği sunucusuz bilişimdir. Sunucusuz bilgi işlemin bir uygulamasına hizmet olarak işlev (FaaS) adı verilir. Bu modelde, bir bulut kullanıcısı, servis sağlayıcının uygulama programlama arayüzü (API) (dolayısıyla "hizmet olarak işlev" adı da buradan gelir) aracılığıyla çağrılan işlevleri tanımlar ve CSP, hizmeti yürüten sunucudaki kaynak tahsisini yönetir. kullanıcının işlevi (bundan dolayı “sunucusuz bilgi işlem” adı verilir; kullanıcı sunucu yönetimi yapmaz). Benzer şekilde, hizmet olarak kapsayıcı (CaaS) bilgi işlem, isteğe bağlı olarak kapsayıcıları, taşınabilir çalışma zamanı paketlerini çalıştırır. FaaS ve CaaS'ın merkezi sunucu yönetimi, hem CSP'ler hem de kullanıcılar için ekonomik açıdan caziptir. CSP, kullanıcılarının iş yüklerini istediği gibi yönetebilir, minimum işletme maliyeti için optimizasyon yapabilir ve kullanıcıların, kullandıkları yürütme süresi için ödeme yaptığı esnek fiyatlandırma uygulayabilir. Kullanıcının sunucu altyapısı tasarımı veya yönetimi konusunda endişelenmesine gerek kalmaz ve böylece geliştirme maliyetleri azalır ve bakım maliyeti CSP'ye nispeten küçük ve öngörülebilir bir oranda dış kaynak olarak sağlanır. 2.3 MicroVM'ler ve AWS Firecracker FaaS ve CaaS sağlayıcıları, çalışan işlevleri ve kapsayıcıları yönetmek için çeşitli sistemler kullanır. Docker, Podman ve LXD gibi konteyner sistemleri, korumalı alan uygulamalarını her ortamda paketlemek ve çalıştırmak için kullanışlı ve hafif bir yol sağlar. Ancak, bulut bilişimin birçok geleneksel biçimi için kullanılan sanal makinelerle karşılaştırıldığında, konteynerler daha az izolasyon ve dolayısıyla daha az güvenlik sunar. Son yıllarda büyük CSP'ler, ekstra güvenlik için geleneksel konteynerleri hafif sanallaştırmayla destekleyen microVM'leri piyasaya sürdü. [1, 55] KVM ile donanım sanallaştırmanın verimliliği ve mikroVM'lerin hafif tasarımı, sanallaştırılmış, kapsayıcıya alınmış veya kapsayıcı benzeri sistemlerdeki kodun neredeyse sanallaştırılmamış kod kadar hızlı ve geleneksel bir kapsayıcıyla karşılaştırılabilir ek yük ile çalışabileceği anlamına gelir. Firecracker [1], AWS Lambda FaaS ve AWS Fargate CaaS iş yüklerinin her birini ayrı bir VM'de izole etmek için AWS tarafından geliştirilen bir microVM'dir. Yalnızca x86 veya ARM Linux-KVM ana bilgisayarlarındaki Linux konuklarını destekler ve konuk sistemlerin kullanımına sınırlı sayıda cihaz sağlar. Bu sınırlamalar, Firecracker'ın kod tabanı boyutu ve çalışan bir VM için bellek yükünün çok hafif olmasına ve aynı zamanda başlatılmasının veya kapatılmasının çok hızlı olmasına olanak tanır. Ek olarak, KVM'nin kullanımı Firecracker'ın gereksinimlerini hafifletir, çünkü bazı sanallaştırma işlevleri çekirdek sistem çağrıları tarafından yönetilir ve ana bilgisayar işletim sistemi VM'leri standart işlemler olarak yönetir. Rust'ta yazılan küçük kod tabanı nedeniyle, önceki sürümlerde güvenlik kusurları tanımlanmış olmasına rağmen Firecracker'ın çok güvenli olduğu varsayılmaktadır (bkz. CVE-2019-18960). İlginç bir şekilde, Firecracker teknik incelemesi, mikro mimari saldırıların saldırgan modelinin kapsamı içinde olduğunu beyan ediyor [1] ancak konuk ve ana bilgisayar çekirdeği için ortak güvenli sistem yapılandırma önerilerinin ötesinde ayrıntılı bir güvenlik analizi veya mikro mimari saldırılara karşı özel karşı önlemlerden yoksundur. Firecracker belgeleri, bölüm 2.6.1'de ele aldığımız belirli bir karşı önlem listesini içeren sistem güvenliği önerileri [8] sağlar. 2.4 Erime ve MDS 2018 yılındaki Meltdown [32] saldırısı, spekülatif olarak erişilen verilerin, bir önbellek yan kanalına kodlanarak güvenlik sınırlarının ötesine sızdırılabileceğini gösterdi. Bu durum çok geçmeden mikro mimari veri örnekleme (MDS) olarak bilinen, Fallout [14], Rogue In-flight Data Load (RIDL) [50], TSX Asenkron Abort (TAA) [50] ve Zombi yükü [46]. Bu saldırıların tümü spekülatif yürütmeden yararlanmak için aynı genel modeli izler: (1) Kurban, gizli verileri işleyen bir programı çalıştırır ve gizli veriler bir önbellek veya CPU arabelleğinden geçer. (2) Saldırgan, CPU'nun yanlışlıkla gizli verilere ihtiyaç duyulacağını tahmin etmesine neden olacak özel olarak seçilmiş bir talimatı çalıştırır. CPU, gizli verileri saldırganın talimatına iletir. (3) İletilen gizli veriler, saldırganın erişim yetkisine sahip olduğu bir diziye okunan bellek için indeks olarak kullanılır ve bu dizinin belirli bir satırının önbelleğe alınmasına neden olur. (4) CPU veri kontrolünü bitirir ve gizli verinin yanlış iletildiğine karar verir ve yürütme durumunu iletilmeden önceki durumuna geri döndürür, ancak önbelleğin durumu geri döndürülmez. (5) Saldırgan hangi satırın önbelleğe alındığını görmek için tüm diziyi araştırır; bu satırın indeksi gizli verinin değeridir. Orijinal Meltdown güvenlik açığı, önbellek iletmeyi hedefliyordu ve önbellekte bulunan herhangi bir bellek adresinden bu şekilde veri çıkarılmasına izin veriyordu. MDS saldırıları, çekirdek mikro mimarisindeki daha küçük ve daha spesifik arabellekleri hedef alır ve böylece önemli ölçüde farklı bir şekilde hafifletilen, ilişkili ancak farklı bir saldırı sınıfı oluşturur. Meltdown nispeten seyrek olarak güncellenen ve tüm çekirdekler, iş parçacıkları ve işlemler arasında paylaşılan ana belleği hedeflerken, MDS saldırıları çekirdeklerde yerel olan (bazen iş parçacıkları arasında paylaşılsa da) ve yürütme sırasında daha sık güncellenen arabellekleri hedefleme eğilimindedir. . Şekil 1, Intel CPU'lara yönelik bilinen başlıca MDS saldırı yollarını ve Intel ve bunları bildiren araştırmacılar tarafından farklı varyantlara verilen adları göstermektedir. En genel anlamda Intel, CPU'larındaki MDS güvenlik açıklarını, verilerin spekülatif olarak iletildiği belirli ara belleğe göre sınıflandırır; çünkü bu arabellekler bir dizi farklı işlem için kullanılma eğilimindedir. RIDL MDS güvenlik açıkları, CPU'nun yük bağlantı noktasından sızan değişkenler için Mikro Mimari Yük Bağlantı Noktası Veri Örneklemesi (MLPDS) ve CPU'nun LFB'sinden sızan değişkenler için Mikro Mimari Doldurma Arabelleği Veri Örneklemesi (MFBDS) olarak kategorize edilebilir. Aynı doğrultuda Intel, mağaza arabelleğinden bir sızıntı içerdiği için Fallout güvenlik açığını Mikro Mimari Mağaza Arabelleği Veri Örneklemesi (MSBDS) olarak adlandırıyor. Vektör Kayıt Örneklemesi (VRS), mağaza arabelleğinden geçerken vektör işlemleri tarafından işlenen verileri hedefleyen bir MSBDS çeşididir. VERW bypass'ı bir hatadan yararlanıyor 2.4.1 Temel MDS Çeşitleri LFB'ye eski ve potansiyel olarak gizli verileri yükleyen MFBDS için mikro kod düzeltmeleri. Sızıntının temel mekanizması aynıdır ve VERW bypass'ı MFBDS'nin özel bir durumu olarak düşünülebilir. L1 Veri Çıkarma Örneklemesi (L1DES), L1 veri önbelleğinden çıkarılan verilerin LFB'den geçtiği ve MDS saldırısına karşı savunmasız hale geldiği MFBDS'nin başka bir özel durumudur. Özellikle, L1DES, saldırganın gizli verinin CPU'daki varlığını tetikleyebildiği (onu çıkararak) bir durumken, diğer MDS saldırıları doğrudan kurbanın gizli verilere erişerek bu verileri doğru CPU arabelleğine getirmesine dayanır. [37], Intel tarafından MLPDS varyantları [25] olarak sınıflandırılan bir MDS saldırıları kategorisidir. Medusa'daki güvenlik açıkları, Intel işlemcilerin yazma-birleştirme (WC) arabelleğindeki depoları spekülatif olarak birleştirmek için kullanılan kusurlu desen eşleştirme algoritmalarından yararlanıyor. Intel, WC arabelleğinin yük bağlantı noktasının bir parçası olduğunu düşünüyor, bu nedenle Intel bu güvenlik açığını bir MLPDS durumu olarak sınıflandırıyor. Spekülatif bir sızıntıya neden olmak için her biri yazma-birleştirme arabelleğinin farklı bir özelliğini kullanan bilinen üç Medusa çeşidi vardır: 2.4.2 Medusa. Medusa Arızalı bir yük, eşleşen bir önbellek satırı uzaklığıyla daha önceki bir yükle spekülatif olarak birleştirilir. Önbellek Dizini Oluşturma: Yanlış hizalanmış bir bellek hatasını tetikleyen bağımlı bir yükün takip ettiği geçerli bir depolama, WC'den rastgele verilerin iletilmesine neden olur. Hizalanmamış Depolamadan Yüklemeye İletme: : Arızalı bir REP MOV komutunun ardından bağımlı bir yük, farklı bir REP MOV'un verilerini sızdırır. Shadow REP MOV Donanım güvenlik açığı TSX Eşzamansız Durdurma (TAA) [24], bir MDS saldırısının gerçekleştirilmesi için farklı bir spekülasyon mekanizması sağlar. Standart MDS saldırıları, standart speküle yürütmeyle kısıtlı verilere erişirken, TAA, TSX tarafından uygulanan bir atomik bellek işlemini kullanır. Bir atomik bellek işlemi, örneğin başka bir işlemin işlem tarafından kullanılmak üzere işaretlenmiş bir önbellek satırını okuması veya işlemin bir hatayla karşılaşması nedeniyle eşzamansız bir iptalle karşılaştığında, işlemdeki tüm işlemler, işlem başlamadan önceki mimari durumuna geri alınır. Ancak, bu geri alma sırasında, işlemin içinde yürütülmeye başlamış olan talimatlar, diğer MDS saldırılarının (2) ve (3) numaralı adımlarında olduğu gibi spekülatif yürütmeye devam edebilir. TAA, TSX'i destekleyen tüm Intel işlemcileri etkiler ve diğer MDS saldırılarından etkilenmeyen belirli yeni işlemciler durumunda, MDS azaltımları veya TAA'ya özgü azaltımlar (TSX'in devre dışı bırakılması gibi), TAA'ya karşı koruma sağlamak için yazılımda uygulanmalıdır [24]. 2.4.3 TSX Eşzamansız Durdurma. 2.4.4 Azaltmalar. , en savunmasız CPU'lardaki mikro kod ürün yazılımı yamalarıyla bunların etkisi hafifletilebilir. Meltdown ve MDS sınıfı güvenlik açıkları, düşük seviyeli mikro mimari operasyonlardan yararlansa da Sayfa tablosu izolasyonu. böylece kullanıcı düzeyindeki bir işlem, minimum ek yük ile çekirdeğe sistem çağrısı yapabilir. Sayfa tablosu izolasyonu (ilk olarak Gruss ve diğerleri tarafından KAISER [19] olarak önerilmiştir) yalnızca gerekli minimum çekirdek belleğini kullanıcı sayfa tablosuna eşler ve yalnızca çekirdek tarafından erişilebilen ikinci bir sayfa tablosu sunar. Kullanıcı işleminin çekirdek sayfa tablosuna erişememesi nedeniyle, çekirdek belleğinin küçük ve özel olarak seçilmiş bir kısmı dışındaki tüm erişimler, Meltdown saldırısının başladığı alt düzey önbelleklere ulaşmadan önce durdurulur. Geçmişte, çekirdek sayfa tabloları, kullanıcı düzeyindeki işlem sayfa tablolarına dahil edilmiştir, Çekirdekteki CPU arabelleklerini hedef alan MDS saldırıları, daha düşük düzeyde ve daha hedefe yönelik bir savunma gerektirir. Intel, birinci düzey veri (L1d) önbelleği (önbellek zamanlaması yan kanal saldırılarının ortak hedefi) temizlendiğinde veya VERW talimatı çalıştırıldığında savunmasız arabelleklerin üzerine yazan bir mikro kod güncellemesi sundu [25]. Çekirdek daha sonra güvenilmeyen bir işleme geçiş yaparken arabellek üzerine yazmayı tetikleyerek MDS saldırılarına karşı koruma sağlayabilir. Arabellek üzerine yazma. Arabellek üzerine yazma azaltma, MDS saldırılarını kaynağında hedefler, ancak en hafif tabirle kusurludur. SMT etkinleştirildiğinde, işlemler aynı çekirdek üzerinde aynı anda çalışan iş parçacıklarından gelen saldırılara karşı savunmasız kalır (çünkü her iki iş parçacığı, her iki iş parçacığında da etkin işlem aslında değişmeden savunmasız arabellekleri paylaşır). Ayrıca, orijinal arabellek üzerine yazma mikrokodu güncellemesinden kısa bir süre sonra, RIDL ekibi şunları buldu: bazı Skylake CPU'larında, eski ve potansiyel olarak hassas verilerle ara belleklerin üzerine yazıldığını [50] ve azaltımların etkin ve SMT devre dışı bırakıldığında bile savunmasız kaldığını gösterdi. Yine diğer işlemciler TAA'ya karşı savunmasızdır ancak TAA dışı MDS saldırılarına karşı savunmasızdır ve arabellek üzerine yazma mikrokodu güncellemesi almamıştır ve bu nedenle MDS saldırılarını önlemek için TSX'in tamamen devre dışı bırakılmasını gerektirir [20, 24]. 2.5 Hayalet 2018'de Jan Horn ve Paul Kocher [30] bağımsız olarak ilk Spectre varyantlarını bildirdiler. O zamandan bu yana birçok farklı Spectre varyantı [22, 30, 31, 33] ve alt varyantları [10, 13, 16, 28, 52] keşfedildi. Spectre saldırıları, CPU'nun mimari olarak erişilemeyen belleğe spekülatif olarak erişmesine ve verileri mimari duruma sızdırmasına neden olur. Bu nedenle tüm Spectre çeşitleri üç bileşenden oluşur [27]: İlk bileşen, spekülatif olarak yürütülen Spectre aygıtıdır. Spectre varyantları genellikle yararlandıkları yanlış tahminin kaynağına göre ayrılır. Koşullu bir doğrudan dallanmanın sonucu, örneğin, Model Geçmişi Tablosu (PHT) tarafından tahmin edilir. PHT'nin yanlış tahminleri, yükleme ve saklama talimatları için spekülatif sınır kontrolünün atlanmasına yol açabilir [13, 28, 30]. Dolaylı bir sıçramanın dal hedefi, Dal Hedef Tamponu (BTB) tarafından tahmin edilir. Eğer bir saldırgan BTB'nin yanlış tahmin edilmesinin sonucunu etkileyebilirse spekülatif getiri odaklı programlama saldırıları mümkündür [10, 13, 16, 30]. Aynı durum, dönüş talimatlarının yürütülmesi sırasında dönüş adreslerini tahmin eden Dönüş Yığın Arabelleği (RSB) tarafından sunulan tahminler için de geçerlidir [13, 31, 33]. Son sonuçlar, bazı modern CPU'ların, RSB'nin yetersiz kalması durumunda dönüş adresi tahminleri için BTB'yi kullandığını gösterdi [52]. Spectre saldırılarının bir başka kaynağı da depodan yüklemeye bağımlılıkların tahminidir. Bir yükün önceki bir depoya bağlı olmayacak şekilde yanlış tahmin edilmesi durumunda, spekülatif bir depo atlamasına yol açabilecek eski veriler üzerinde spekülatif olarak yürütülür [22]. Bu gadget'ların tümü varsayılan olarak istismar edilemez ancak şu anda tartışılan diğer iki bileşene bağlıdır. İkinci bileşen, bir saldırganın yukarıda bahsedilen araçlara yapılan girişleri nasıl kontrol ettiğidir. Saldırganlar, gadget giriş değerlerini doğrudan kullanıcı girişi, dosya içerikleri, ağ paketleri veya diğer mimari mekanizmalar aracılığıyla tanımlayabilir. Öte yandan saldırganlar, yük değeri enjeksiyonu [12] veya kayan nokta değeri enjeksiyonu [42] yoluyla aygıta geçici olarak veri enjekte edebilirler. Saldırganlar, spekülasyon penceresi sırasında hangi verilere veya talimatlara erişildiğini veya yürütüldüğünü etkileyebilirlerse gadget girişlerini başarılı bir şekilde kontrol edebilirler. Üçüncü bileşen, spekülatif mikro mimari durumu mimari duruma aktarmak ve dolayısıyla spekülatif olarak erişilen verileri kalıcı bir ortama sızdırmak için kullanılan gizli kanaldır. Gizli önbellek kanalları [39, 40, 54], kurban kodunun spekülatif olarak erişilen gizli verilere [30] bağlı olarak geçici bir bellek erişimi gerçekleştirmesi durumunda uygulanabilir. Bir sırra spekülatif olarak erişilirse ve çekirdekteki bir ara belleğe yüklenirse, saldırgan, sızdırılan verileri geçici olarak saldırganın iş parçacığına aktarmak için MDS tabanlı bir kanala [14, 46, 50] güvenebilir ve burada veriler mimariye aktarılır. örneğin bir önbellek gizli kanalı aracılığıyla durum. Son olarak, eğer kurban gizli verilere bağlı olarak kod çalıştırıyorsa, saldırgan port çekişmesini gözlemleyerek sırrı öğrenebilir [3, 11, 18, 43, 44]. Çeşitli Spectre varyantlarını hafifletmek için birçok karşı önlem geliştirildi. Gerekli üç bileşenden birinin kaldırılması durumunda belirli bir Spectre çeşidi etkili bir şekilde devre dışı bırakılır. Spectre aygıtlarına yapılan girdiler üzerinde kontrolü olmayan bir saldırganın başarılı bir saldırı başlatması pek olası değildir. Spekülatif durumu mimari duruma dönüştürecek gizli bir kanal mevcut olmadığında da aynı durum geçerlidir. Ancak bunu garanti etmek genellikle zor olduğundan Spectre'ın karşı önlemleri esas olarak yanlış tahminleri durdurmaya odaklanıyor. Kritik kod bölümlerinden önce koruma talimatlarının eklenmesi, bu noktanın ötesinde spekülatif yürütmeyi devre dışı bırakır ve bu nedenle genel bir karşı önlem olarak kullanılabilir. Ancak yüksek performans yükü nedeniyle daha spesifik karşı önlemler geliştirildi. Spectre-BTB karşı önlemleri Retpoline'i [48] ve IBRS, STIBP veya IBPB [23] gibi mikro kod güncellemelerini içerir. Spectre-RSB ve Spectre-BTB-via-RSB, kötü amaçlı girişlerin üzerine yazmak ve RSB'nin taşmasını önlemek için RSB'yi değerlerle doldurarak veya IBRS mikrokod güncellemelerini yükleyerek hafifletilebilir. Spectre-STL, SSBD mikrokod güncellemesiyle hafifletilebilir [23]. Bir saldırganın paylaşılan dal tahmin arabelleklerine müdahale etmesini engellemenin bir başka önemli seçeneği de SMT'yi devre dışı bırakmaktır. SMT'nin devre dışı bırakılması, önemli bir performans kaybı pahasına şube tahmini donanım kaynaklarını eşzamanlı kiracılar arasında etkili bir şekilde bölüştürür. 2.5.1 Azaltmalar. 2.6 AWS'nin izolasyon modeli Firecracker, özellikle sunucusuz ve konteyner uygulamaları için tasarlanmıştır [1] ve şu anda AWS'nin Fargate CaaS ve Lambda FaaS tarafından kullanılmaktadır. Bu hizmet modellerinin her ikisinde de Firecracker, her bir Fargate görevini veya Lambda olayını destekleyen birincil izolasyon sistemidir. Bu hizmet modellerinin her ikisi de çok yüksek sayıda, nispeten küçük ve kısa ömürlü görevleri yürütmek için tasarlanmıştır. AWS, sonunda Firecracker haline gelen izolasyon sisteminin tasarım gereksinimlerini şu şekilde sıralıyor: : Birden fazla işlevin aynı donanım üzerinde çalışması güvenli olmalı, ayrıcalık yükseltmeye, bilgilerin ifşa edilmesine, gizli kanallara ve diğer risklere karşı korunmalıdır. Yalıtım Binlerce işlevi tek bir makinede minimum atıkla çalıştırmak mümkün olmalıdır. Yük ve Yoğunluk: İşlevlerin yerel olarak çalışmaya benzer şekilde performans göstermesi gerekir. Performansın aynı zamanda tutarlı olması ve aynı donanımdaki komşuların davranışlarından izole edilmesi gerekir. Performans: : Lambda, işlevlerin isteğe bağlı Linux ikili dosyaları ve kitaplıkları içermesine olanak tanır. Bunlar kod değişikliği veya yeniden derleme olmadan desteklenmelidir. Uyumluluk Yeni işlevleri hızlı bir şekilde başlatmak ve eski işlevleri temizlemek mümkün olmalıdır. Hızlı Geçiş: Her işlevin yetki sahibi olduğu kaynakları değil, yalnızca ihtiyaç duyduğu kaynakları tükettiği şekilde CPU, bellek ve diğer kaynakların aşırı kullanımı mümkün olmalıdır. [1] Yumuşak Tahsis: Özellikle gerekliliğiyle ilgileniyoruz ve mikro mimari saldırıların Firecracker tehdit modeli kapsamında ilan edildiğini vurguluyoruz. AWS'nin halka açık Firecracker Git deposundaki "tasarım" sayfası izolasyon modelini detaylandırır ve Şekil 2'de yeniden oluşturduğumuz kullanışlı bir şema sunar. Bu şema çoğunlukla ayrıcalık artışına karşı korumayla ilgilidir. En dıştaki koruma katmanı, VMM'yi ve diğer yönetim bileşenlerini çalıştırırken Firecracker'ın ana bilgisayar çekirdeğine erişimini sınırlamak için konteyner izolasyon tekniklerini kullanan gardiyandır. izolasyon Firecracker'ın ana bilgisayar kullanıcı alanındaki tek bir işlemin iş parçacıkları olarak işlenmesi. Firecracker işleminde kullanıcının iş yükü diğer iş parçacıklarında çalıştırılır. İş yükü iş parçacıkları, sanal makinenin konuk işletim sistemini ve konukta çalışan tüm programları yürütür. Kullanıcı kodunun sanal makine konuğunda çalıştırılması, ana bilgisayarla olan doğrudan etkileşimini, KVM ve Firecracker yönetim iş parçacıklarının belirli bölümleri ile önceden ayarlanmış etkileşimlerle sınırlar. Yani ana bilgisayar çekirdeği açısından bakıldığında, VMM ve kullanıcının kodunu içeren VM aynı süreçte çalıştırılır. AWS'nin her VM'nin tek bir süreçte bulunduğunu belirtmesinin nedeni budur. Ancak VM, donanım sanallaştırma teknikleri yoluyla izole edildiğinden, kullanıcının kodu, konuk çekirdeği ve VMM ayrı adres alanlarında çalışır. Bu nedenle, konuğun kodu, konuğun adres alanında eşlenmediğinden, VMM'ye veya konuk çekirdeği bellek adreslerine mimari olarak veya geçici olarak erişemez. Geriye kalan mikro mimari saldırı yüzeyi, adres alanı sınırlarını göz ardı ederek CPU dahili arabelleklerinden bilgi sızdıran MDS saldırıları ve bir saldırganın kendi kendine bilgi sızdırmak için diğer süreçlerin dal tahminlerini manipüle ettiği Spectre saldırılarıyla sınırlıdır. Şekil 2'de gösterilmeyen ancak AWS'nin tehdit modeli açısından aynı derecede önemli olan husus, özellikle gereksinimi ışığında, donanım paylaşıldığında işlevlerin birbirinden . Ana bilgisayar çekirdeğinin tehlikeye atılmasının herhangi bir misafirin güvenliğini tehlikeye atabileceği gerçeğinin yanı sıra, ana bilgisayar donanımını hedef alan mikro mimari saldırılar da kullanıcı kodunu doğrudan tehdit edebilir. Tek bir Firecracker işlemi, bir kullanıcı işlevine sahip bir sanal makineyi çalıştırmak için gerekli tüm iş parçacıklarını içerdiğinden, geçici tahsis, ana bilgisayar işletim sistemi tarafından kolayca gerçekleştirilebilir [1]. Bu, sanal makine izolasyonunun üstünde standart Linux işlem izolasyon sistemlerinin mevcut olduğu anlamına gelir. geçici tahsis yalıtılmasıdır Firecracker belgeleri ayrıca mikro mimari yan kanallara karşı koruma sağlamak için aşağıdaki önlemleri önermektedir [8]: 2.6.1 Havai Fişek güvenlik önerileri. • SMT'yi devre dışı bırakın • Çekirdek sayfa tablosu izolasyonunu etkinleştirin • Çekirdek kame-sayfa birleştirmesini devre dışı bırakın • Spectre-BTB azaltmayla derlenmiş bir çekirdek kullanın (örneğin, x86'da IBRS ve IBPB) • Spectre-PHT azaltımını doğrulayın • L1TF azaltımını etkinleştirin • Spectre-STL azaltımını etkinleştirin • Belleği Rowhammer azaltmayla kullanın • Takas işlemini devre dışı bırakın veya güvenli takas kullanın Bu makale . arxiv'de CC BY-NC-ND 4.0 DEED lisansı altında mevcuttur [1] Sanallaştırılmış halka 0 ve halka 3, neredeyse yerel kod yürütmenin başarılmasının temel nedenlerinden biridir.