AWS फायरक्रैकर VMM की माइक्रोआर्किटेक्चरल सुरक्षा: माइक्रोआर्किटेक्चरल हमले और बचाव का विश्लेषण

लिंक की तालिका

• सार और परिचय
• पृष्ठभूमि
• ख़तरा मॉडल
• पटाखों की रोकथाम प्रणालियों का विश्लेषण
• फायरक्रैकर माइक्रोवम्स में माइक्रोआर्किटेक्चरल हमले और बचाव का विश्लेषण
• निष्कर्ष, आभार और संदर्भ

5. पटाखा माइक्रोवम्स में सूक्ष्म वास्तुकला संबंधी हमलों और बचाव का विश्लेषण

इस खंड में हम फायरक्रैकर माइक्रोवीएम पर कई माइक्रोआर्किटेक्चरल साइड-चैनल और सट्टा हमले PoCs का अपना विश्लेषण प्रस्तुत करते हैं। हम इन PoCs को बेयर मेटल और फायरक्रैकर इंस्टेंस पर टेस्ट करते हैं, और विभिन्न परिदृश्यों में प्रासंगिक माइक्रोकोड सुरक्षा का परीक्षण करते हैं। हम अपने परीक्षण इंटेल स्काईलेक 4114 सीपीयू वाले सर्वर पर चलाते हैं

जिसमें वर्चुअलाइजेशन हार्डवेयर एक्सटेंशन और एसएमटी सक्षम है। सीपीयू माइक्रोकोड संस्करण 0x2006b06[2] पर चलता है। होस्ट ओएस उबंटू 20.04 है जिसमें लिनक्स 5.10 कर्नेल है। हमने लिनक्स कर्नेल 5.4 के साथ उबंटू 18.04 अतिथि को चलाने के लिए फायरक्रैकर v1.0.0 और v1.4.0 का उपयोग किया, जो जुलाई 2023 तक का नवीनतम संस्करण है, जिसे क्विक-स्टार्ट गाइड[3] का पालन करते समय अमेज़ॅन द्वारा प्रदान किया जाता है।

संक्षेप में, AWS फायरक्रैकर के साथ प्रदान किया गया अनुशंसित प्रोडक्शन होस्ट सेटअप किरायेदारों को दुर्भावनापूर्ण पड़ोसियों से बचाने के मामले में अपर्याप्त है। इसलिए फायरक्रैकर अपने द्वारा दावा किए गए अलगाव की गारंटी प्रदान करने में विफल रहता है। ऐसा इसलिए है क्योंकि

(1) हम एक मेडुसा वैरिएंट की पहचान करते हैं जो केवल तभी शोषक हो जाता है जब इसे माइक्रोवीएम पर चलाया जाता है। इसके अलावा, अनुशंसित प्रतिवाद में साइड-चैनल या अधिकांश अन्य मेडुसा वैरिएंट को कम करने के लिए आवश्यक कदम शामिल नहीं हैं।

(2) हम दिखाते हैं कि अनुशंसित प्रतिवाद लागू करते समय किरायेदारों को स्पेक्ट्रे-पीएचटी या स्पेक्ट्रे-बीटीबी के माध्यम से प्रेरित सूचना लीक से ठीक से संरक्षित नहीं किया जाता है। स्पेक्ट्रे-पीएचटी वेरिएंट एसएमटी को अक्षम करने पर भी एक समस्या बने रहते हैं।

(3) हमने फायरक्रैकर v1.0.0 और v1.4.0 के बीच PoC प्रदर्शन में कोई अंतर नहीं देखा।

हम इस निष्कर्ष पर पहुंचे हैं कि फायरक्रैकर द्वारा प्रदान की गई वर्चुअलाइजेशन परत का माइक्रोआर्किटेक्चरल हमलों पर बहुत कम प्रभाव पड़ता है, और फायरक्रैकर की सिस्टम सुरक्षा सिफारिशें अपर्याप्त हैं।

5.1 मेडुसा

हमने अपने परीक्षण सिस्टम के बेयर मेटल और फायरक्रैकर वीएम में मेडुसा [37] साइड-चैनल (इंटेल द्वारा एम.एल.पी.डी.एस. [25] के एम.एल.पी.डी.एस. वेरिएंट के रूप में वर्गीकृत) के लिए मोघिमी के पी.ओ.सी. [35] का मूल्यांकन किया। सेक्शन 2.4.2 में वर्णित तीन ज्ञात वेरिएंट में से प्रत्येक के लिए एक लीकिंग पी.ओ.सी. है। हमने पी.ओ.सी. लाइब्रेरी से दो पीड़ित प्रोग्राम का उपयोग किया:

• "ब्लॉक राइट" प्रोग्राम एक लूप में बड़ी मात्रा में लगातार डेटा लिखता है (ताकि प्रोसेसर दोहराए गए स्टोर की पहचान कर सके और उन्हें संयोजित कर सके)।

• "REP MOV" प्रोग्राम एक समान ऑपरेशन करता है, लेकिन लूप में डेटा के छोटे ब्लॉकों को स्थानांतरित करने वाले कई निर्देशों के बजाय REP MOV निर्देश के साथ।

5.1.1 परिणाम। तालिका 1 उन मामलों को दिखाती है जिसमें कर्नेल में सभी माइक्रोआर्किटेक्चरल सुरक्षा अक्षम होने पर डेटा सफलतापूर्वक लीक हो जाता है। बाएं दो कॉलम तीन मेडुसा PoCs और दो शामिल पीड़ित कार्यक्रमों के संभावित संयोजनों को दिखाते हैं। दाएं कॉलम इंगित करते हैं कि कौन से कॉन्फ़िगरेशन नंगे धातु पर काम करते हैं और गुप्त और लीकिंग प्रोग्राम समानांतर फायरक्रैकर इंस्टेंस में चल रहे हैं। सबसे उल्लेखनीय रूप से, कैश इंडेक्सिंग वैरिएंट के साथ, ब्लॉक राइट सीक्रेट केवल फायरक्रैकर के साथ काम करता है। यह संभवतः मेमोरी एड्रेस वर्चुअलाइजेशन के कारण है जो वर्चुअल मशीन प्रदान करती है: अतिथि केवल KVM द्वारा मैप किए गए वर्चुअल मेमोरी क्षेत्रों को देखता है, और KVM मेमोरी एक्सेस निर्देशों को ट्रैप करता है और अतिथि की ओर से लेनदेन को संभालता है।

हमने बेयर मेटल और फायरक्रैकर वीएम पर हमलावर और पीड़ित पीओसी के प्रत्येक संयोजन के खिलाफ एमडीएस और नोस्मट सुरक्षा की प्रभावशीलता का परीक्षण किया। तालिका 2 बेयर मेटल और फायरक्रैकर परिदृश्यों में मेडुसा हमलों को रोकने के लिए आवश्यक सुरक्षा को सूचीबद्ध करती है। फायरक्रैकर में चार कमजोरियों में से, केवल एक को अकेले नोस्मट द्वारा कम किया जाता है, और AWS स्पष्ट रूप से mds सुरक्षा को सक्षम करने की अनुशंसा नहीं करता है, हालांकि अधिकांश लिनक्स वितरण डिफ़ॉल्ट रूप से इसे सक्षम करके आते हैं। कहने का तात्पर्य यह है कि एक मल्टी-टेनेंट क्लाउड प्लेटफ़ॉर्म फायरक्रैकर का उपयोग इस तरह से कर सकता है जो AWS के अनुशंसित सुरक्षा उपायों के अनुरूप हो और फिर भी अधिकांश मेडुसा वेरिएंट के लिए असुरक्षित हो, जिसमें एक ऐसा भी शामिल है जहाँ फायरक्रैकर VMM स्वयं उपयोगकर्ता के डेटा को लीक करता है जो अन्यथा लीक नहीं होता।

5.2 आरआईडीएल और अधिक

इस खंड में, हम वैन शाइक एट अल के 2019 पेपर [50] के साथ प्रदान किए गए RIDL PoC प्रोग्राम [51] का मूल्यांकन प्रस्तुत करते हैं। RIDL MDS हमलों का एक वर्ग है जो CPU के अंदर बफ़र्स (कैश या मेमोरी से नहीं) से सट्टा लोड का फायदा उठाता है। RIDL PoC रिपॉजिटरी में पेपर के बाद के परिशिष्टों में जारी किए गए हमलों के उदाहरण और साथ ही फ़ॉलआउट MDS हमले का एक प्रकार भी शामिल है।

5.2.1 परिणाम। तालिका 3 में हमने जिन RIDL PoCs का परीक्षण किया है, उनके बारे में कुछ बुनियादी जानकारी और हमलों को रोकने में प्रासंगिक प्रतिवादों की प्रभावकारिता दिखाई गई है। हमने फायरक्रैकर माइक्रोवीएम सिस्टम की बढ़ी हुई हार्डवेयर सुरक्षा के अमेज़न के दावों का मूल्यांकन करने के लिए बेयर मेटल और फायरक्रैकर में हमलों की तुलना की। फायरक्रैकर सिस्टम पर परीक्षणों के लिए, हम होस्ट सिस्टम (H) और फायरक्रैकर गेस्ट कर्नेल (VM) पर सक्षम प्रतिवाद झंडों के बीच अंतर करते हैं। nosmt और mds कर्नेल झंडों के अलावा, हमने अन्य प्रासंगिक झंडों (अनुभाग 2.4.4, [21] देखें) का परीक्षण किया, जिसमें kaslr, pti और l1tf शामिल हैं, लेकिन यह नहीं पाया कि इनका इनमें से किसी भी प्रोग्राम पर कोई प्रभाव पड़ा। हमने tsx_async_abort शमन को बाहर रखा क्योंकि हमने जिस CPU पर परीक्षण किया, उसमें mds शमन शामिल है जो tsx_async_abort कर्नेल फ़्लैग को अनावश्यक बनाता है [20]।

सामान्य तौर पर, हमने पाया कि mds सुरक्षा RIDL हमलों के बहुमत के खिलाफ पर्याप्त रूप से सुरक्षा नहीं करती है। हालांकि, SMT को अक्षम करने से इनमें से अधिकांश शोषण कम हो जाते हैं। यह इंटेल के [25] और लिनक्स डेवलपर्स के [21] कथनों के अनुरूप है कि हाइपरथ्रेड्स में MDS हमलों को रोकने के लिए SMT को अक्षम किया जाना चाहिए। इन PoCs में दो आउटलेयर हैं संरेखण_लिखें, जिसके लिए होस्ट पर nosmt और mds दोनों की आवश्यकता होती है, और pgtable_leak_notsx, जिसे केवल mds प्रतिवाद द्वारा कम किया जाता है। संरेखण_लिखें पर निर्भर लीक अटकलों को ट्रिगर करने के लिए पेज टेबल फॉल्ट लीक के बजाय संरेखण गलती का उपयोग करता है [50]। RIDL पेपर [50] और संबंधित VRS शोषण के इंटेल के प्रलेखन [26] इस बारे में स्पष्ट नहीं हैं कि pgtable_leak_notsx के व्यवहार के लिए एक सरल और उचित व्याख्या है, जो इन PoCs में एक प्रमुख कारण से अद्वितीय है: यह एकमात्र ऐसा शोषण है जो किसी अन्य थ्रेड से लीक होने के बजाय एकल थ्रेड के भीतर सुरक्षा सीमाओं (कर्नेल से पेज टेबल मान लीक करना) को पार करता है। यह स्वयं स्पष्ट है कि मल्टी-थ्रेडिंग को अक्षम करने से इस एकल-थ्रेडेड शोषण पर बहुत कम प्रभाव पड़ेगा। हालाँकि, mds काउंटरमेज़र एक ही थ्रेड के भीतर कर्नेलप्रिविलेज निष्पादन से उपयोगकर्ता-विशेषाधिकार निष्पादन पर स्विच करने से पहले माइक्रोआर्किटेक्चरल बफ़र्स को फ्लश करता है, LFB से कर्नेल कोड द्वारा एक्सेस किए गए पेज टेबल डेटा को मिटा देता है, इससे पहले कि हमलावर उपयोगकर्ता कोड इसे लीक कर सके।

मेडुसा के विपरीत, इनमें से अधिकांश PoC को AWS द्वारा smt को अक्षम करने की अनुशंसा द्वारा कम किया जाता है। हालाँकि, मेडुसा की तरह, फायरक्रैकर VMM स्वयं इन हमलों के विरुद्ध कोई माइक्रोआर्किटेक्चरल सुरक्षा प्रदान नहीं करता है।

5.3 स्पेक्ट्रे

इसके बाद हम स्पेक्ट्रे की कमज़ोरियों पर ध्यान केंद्रित करेंगे। स्पेक्ट्रे हमलों की पहली बार खोज के बाद से कई जवाबी उपाय विकसित किए गए हैं, उनमें से कई या तो (महत्वपूर्ण) प्रदर्शन दंड के साथ आते हैं या केवल आंशिक रूप से हमले को कम करते हैं। इसलिए,

सिस्टम ऑपरेटरों को अक्सर प्रदर्शन बनाम सुरक्षा व्यापार-बंद के लिए निर्णय लेना पड़ता है। इस खंड में हम पहले वर्णित दोनों खतरे मॉडल में फायरक्रैकर किरायेदारों के लिए उपलब्ध स्पेक्ट्रे हमले की सतह का मूल्यांकन करते हैं। स्पेक्ट्रे हमलों की विस्तृत श्रृंखला का मूल्यांकन करने के लिए, हम [15] में दिए गए PoCs पर भरोसा करते हैं। स्पेक्ट्रे-PHT, स्पेक्ट्रे-BTB और स्पेक्ट्रेRSB के लिए, रिपॉजिटरी में प्रत्येक में चार PoCs हैं। वे हमलावर द्वारा BPU को गलत तरीके से प्रशिक्षित करने के तरीके में भिन्न हैं। चार संभावनाएँ हैं (1) समान-प्रक्रिया - हमलावर के पास पीड़ित प्रक्रिया या उसके इनपुट पर नियंत्रण होता है जिससे वह BPU को गलत दिशा में ले जा सकता है - (2) क्रॉस-प्रोसेस - हमलावर पीड़ित प्रक्रिया की शाखा भविष्यवाणियों को प्रभावित करने के लिए एक अलग प्रक्रिया में अपना कोड चलाता है - (a) इन-प्लेस - हमलावर शाखा निर्देश के साथ BPU को गलत दिशा में ले जाता है जो लक्ष्य शाखा के समान वर्चुअल पते पर रहता है जिसे हमलावर पीड़ित प्रक्रिया में गलत भविष्यवाणी करना चाहता है - (b) आउट-ऑफ-प्लेस - हमलावर शाखा निर्देशों के साथ BPU को गलत दिशा में ले जाता है जो पीड़ित प्रक्रिया में लक्ष्य शाखाओं के अनुरूप पतों पर रहता है।

(1) समान-प्रक्रिया: हमलावर के पास बीपीयू को गलत तरीके से प्रभावित करने के लिए पीड़ित प्रक्रिया या उसके इनपुट पर नियंत्रण होता है,

(2) क्रॉस-प्रोसेस: हमलावर पीड़ित प्रक्रिया की शाखा भविष्यवाणियों को प्रभावित करने के लिए एक अलग प्रक्रिया में अपना कोड चलाता है,

(3) इन-प्लेस: हमलावर शाखा निर्देश के साथ BPU को गलत तरीके से प्रशिक्षित करता है जो लक्ष्य शाखा के समान वर्चुअल पते पर रहता है जिसे हमलावर पीड़ित प्रक्रिया में गलत भविष्यवाणी करना चाहता है

(4) आउट-ऑफ-प्लेस: हमलावर बीपीयू को शाखा निर्देशों के साथ गलत तरीके से प्रशिक्षित करता है जो पीड़ित प्रक्रिया में लक्ष्य शाखाओं के अनुरूप पते पर रहते हैं।

पहले दो और बाद की दो स्थितियाँ ऑर्थोगोनल हैं, इसलिए प्रत्येक PoC उनमें से दो को जोड़ता है। स्पेक्ट्रे-एसटीएल के लिए, केवल समान-प्रक्रिया वेरिएंट ही ज्ञात हैं, यही कारण है कि रिपॉजिटरी इस मामले में केवल दो PoC प्रदान करती है। क्रॉस-वीएम प्रयोगों के लिए, होस्ट और गेस्ट कर्नेल के साथ-साथ होस्ट और गेस्ट यूजर लेवल के लिए एड्रेस स्पेस लेआउट रैंडमाइजेशन को अक्षम कर दिया गया है ताकि मिसट्रेनिंग के लिए उपयोग किए जाने वाले संगत पते को ढूंढना आसान हो सके।

5.3.1 परिणाम। AWS द्वारा अनुशंसित काउंटरमेशर्स [8] (उपयोग में आने वाले लिनक्स कर्नेल के लिए डिफ़ॉल्ट, cf. चित्र 5) को होस्ट सिस्टम पर और फायरक्रैकर VMs के अंदर सक्षम करने पर, हम देखते हैं कि स्पेक्ट्रे-RSB को होस्ट पर और VMs के अंदर और पार दोनों जगह सफलतापूर्वक कम किया गया है (cf. तालिका 4)। दूसरी ओर, स्पेक्ट्रे-एसटीएल, स्पेक्ट्रे-बीटीबी और स्पेक्ट्रे-पीएचटी ने विशेष स्थितियों में सूचना लीक होने की अनुमति दी।

स्पेक्ट्रे-एसटीएल के लिए PoCs लीकेज दिखाते हैं। हालाँकि, लीकेज केवल उसी प्रक्रिया और उसी विशेषाधिकार स्तर के भीतर होता है। चूँकि कोई क्रॉस-प्रोसेस वेरिएंट ज्ञात नहीं है, इसलिए हमने स्पेक्ट्रे-एसटीएल के लिए क्रॉसवीएम परिदृश्य का परीक्षण नहीं किया। हमारे उपयोगकर्ता-से-उपयोगकर्ता खतरे के मॉडल में, स्पेक्ट्रे-एसटीएल एक संभावित हमला वेक्टर नहीं है, क्योंकि कोई क्रॉस-प्रोसेस वेरिएंट ज्ञात नहीं है। यदि दो टेनेंट वर्कलोड को एक ही वीएम के भीतर इन-प्रोसेस आइसोलेशन द्वारा अलग किया जाएगा, तो स्पेक्ट्रे-एसटीएल अभी भी एक व्यवहार्य हमला वेक्टर हो सकता है। उपयोगकर्ता-से-होस्ट मॉडल में, स्पेक्ट्रे-एसटीएल को काउंटरमेशर्स द्वारा कम किया जाता है जो वर्तमान लिनक्स कर्नेल में शामिल हैं और डिफ़ॉल्ट रूप से सक्षम हैं।

स्पेक्ट्रे-पीएचटी के लिए, कर्नेल काउंटरमेशर्स में उपयोगकर्ता-पॉइंटर्स का सैनिटाइजेशन और विशेषाधिकार स्तर स्विच पर बाधाओं (lfence) का उपयोग शामिल है। इसलिए हम निष्कर्ष निकालते हैं कि स्पेक्ट्रेपीएचटी होस्ट सिस्टम के लिए बहुत कम या कोई खतरा नहीं है। हालाँकि, ये

यदि वे समानांतर रूप से एक ही भौतिक कोर पर निष्पादित होते हैं, तो शमन दो हाइपरथ्रेड को एक दूसरे से सुरक्षित नहीं रखता है। यही कारण है कि सभी चार स्पेक्ट्रे-पीएचटी मिसट्रेनिंग वेरिएंट होस्ट सिस्टम के साथ-साथ फायरक्रैकर वीएम के अंदर भी पूरी तरह कार्यात्मक हैं। जैसा कि तालिका 4 में देखा जा सकता है, यह तब भी सही रहता है जब SMT अक्षम हो[4]। वास्तव में, दोनों VM को एक ही भौतिक थ्रेड पर पिन करने से स्पेक्ट्रे-पीएचटी का क्रॉस-प्रोसेस आउट-ऑफ-प्लेस संस्करण सक्षम होता है जबकि हमने SMT मामले में लीक नहीं देखा। यह स्पेक्ट्रे-पीएचटी को उपयोगकर्ता-से-उपयोगकर्ता के लिए एक महत्वपूर्ण खतरा बनाता है।

स्पेक्ट्रे-बीटीबी पीओसी आंशिक रूप से कार्यात्मक होते हैं जब एडब्ल्यूएस द्वारा अनुशंसित काउंटरमेशर्स सक्षम होते हैं। मूल संस्करण जो एक ही प्रक्रिया में और एक ही पते पर बीटीबी को गलत तरीके से प्रशिक्षित करता है, वह पूरी तरह कार्यात्मक है जबकि समान-प्रक्रिया आउट-ऑफ-प्लेस गलत तरीके से प्रशिक्षित करना

सफलतापूर्वक कम किया गया। साथ ही, आउट-ऑफ-प्लेस मिस्ट्रेनिंग के माध्यम से प्रक्रिया सीमाओं के पार जानकारी लीक करने के सभी प्रयासों में कोई रिसाव नहीं दिखा। क्रॉस-प्रोसेस इन-प्लेस मिस्ट्रेनिंग के साथ, हालांकि, हमने रिसाव देखा। होस्ट सिस्टम पर, रिसाव SMT से स्वतंत्र हुआ। VM के अंदर, रिसाव केवल तभी हुआ जब सभी वर्चुअल CPU कोर को एक अलग भौतिक थ्रेड को सौंपा गया था। VM में, SMT को अक्षम करने से रिसाव दूर हो गया।

चित्र 5 में सूचीबद्ध प्रतिवादों के अलावा, होस्ट कर्नेल में स्पेक्ट्रे प्रतिवाद हैं जो वीएम प्रविष्टि और निकास बिंदु[5] में संकलित किए गए हैं ताकि दुर्भावनापूर्ण मेहमानों को होस्ट कर्नेल पर हमला करने से पूरी तरह से अक्षम किया जा सके, जबकि कर्नेल वीएम निकास को संभालता है।

संक्षेप में, हम कह सकते हैं कि लिनक्स डिफ़ॉल्ट काउंटरमेशर्स - जो AWS फायरक्रैकर द्वारा अनुशंसित हैं - केवल आंशिक रूप से स्पेक्ट्रे को कम करते हैं। सटीक रूप से, हम दिखाते हैं:

• स्पेक्ट्रे-पीएचटी और स्पेक्ट्रे-बीटीबी अभी भी अतिथि-से-अतिथि परिदृश्य में किरायेदारों के बीच जानकारी लीक कर सकते हैं, भले ही एडब्ल्यूएस द्वारा अनुशंसित प्रतिवाद - जिसमें एसएमटी को अक्षम करना शामिल है - लागू हो।

• होस्ट कर्नेल संभवतः लिनक्स कर्नेल में संकलित अतिरिक्त सावधानियों द्वारा पर्याप्त रूप से सुरक्षित है, ताकि वीएम प्रविष्टियों और निकासों को सुरक्षित रखा जा सके। हालाँकि, यह फायरक्रैकर द्वारा प्रदान किए गए सुरक्षा उपायों के लिए ऑर्थोगोनल है।

देखी गई सभी लीकेज उपयोग में लाए जा रहे फायरक्रैकर संस्करण से स्वतंत्र थी।

5.3.2 मूल्यांकन। हम पाते हैं कि फायरक्रैकर स्पेक्ट्रे के खिलाफ़ शमन में कोई वृद्धि नहीं करता है, बल्कि केवल सामान्य सुरक्षा अनुशंसाओं पर निर्भर करता है, जिसमें होस्ट और गेस्ट कर्नेल द्वारा प्रदान किए गए शमन और वैकल्पिक माइक्रोकोड अपडेट शामिल हैं। इससे भी बदतर, अनुशंसित प्रतिवाद सर्वरलेस अनुप्रयोगों को अन्य किरायेदारों को जानकारी लीक करने से अपर्याप्त रूप से सुरक्षित करते हैं। इसलिए हम दावा करते हैं कि फायरक्रैकर माइक्रोआर्किटेक्चरल स्तर पर अपने अलगाव लक्ष्य को प्राप्त नहीं करता है, भले ही माइक्रोआर्किटेक्चरल हमलों को फायरक्रैकर खतरे के मॉडल के दायरे में माना जाता है।

सतर्क पाठक को आश्चर्य हो सकता है कि स्पेक्ट्रे-बीटीबी एसटीआईबीपी काउंटरमेज के साथ एक समस्या क्यों बनी हुई है (चित्र 5 देखें) क्योंकि इस माइक्रोकोड पैच को शाखा भविष्यवाणी को दूसरे थ्रेड से उत्पन्न होने वाली भविष्यवाणी जानकारी का उपयोग करने से रोकने के लिए डिज़ाइन किया गया था। इसने हमें कुछ समय के लिए हैरान कर दिया जब तक कि हाल ही में Google ने एक सुरक्षा सलाह प्रकाशित नहीं की [6] जो लिनक्स 6.2 में एक दोष की पहचान करती है जो आईबीआरएस सक्षम होने पर एसटीआईबीपी शमन को अक्षम करती रहती है। हमने सत्यापित किया कि कोड अनुभाग जिसे समस्या के लिए जिम्मेदार माना गया था, वह लिनक्स 5.10 स्रोत कोड में भी मौजूद है। इसलिए हमारा अनुमान है कि Google द्वारा पहचानी गई वही समस्या हमारे सिस्टम पर भी होती है।

[2] माइक्रोकोड को नए संस्करण में अपडेट करने से हमारे सिस्टम पर TSX अक्षम हो जाएगा जो TSX-आधारित MDS वेरिएंट के साथ परीक्षण को असंभव बना देगा।

[3] https://github.com/firecracker-microvm/firecracker/blob/dbd9a84b11a63b5e5bf201e244fe83f0bc76792a/docs/getting-started.md

[4] यह हमलावर और पीड़ित प्रक्रिया को एक ही कोर पर पिन करके सिम्युलेट किया जाता है ((1PT))

[5] https://elixir.bootlin.com/linux/v5.10/source/arch/x86/kvm/vmx/vmenter.S#L191

[6] https://github.com/google/security-research/security/advisories/GHSA-mj4w6495-6crx