AWS फायरक्रैकर VMM की माइक्रोआर्किटेक्चरल सुरक्षा: पृष्ठभूमि

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

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

2। पृष्ठभूमि

2.1 केवीएम

लिनक्स कर्नेल-आधारित वर्चुअल मशीन (KVM) [29] इंटेल VT-x या AMD-V जैसी हार्डवेयर-सहायता प्राप्त वर्चुअलाइजेशन सुविधाओं का एक अमूर्त रूप प्रदान करता है जो आधुनिक CPU में उपलब्ध हैं। निकट-देशी निष्पादन का समर्थन करने के लिए, मौजूदा कर्नेल मोड और उपयोगकर्ता मोड के अलावा लिनक्स कर्नेल में एक अतिथि मोड जोड़ा जाता है। यदि लिनक्स अतिथि मोड में है, तो KVM हार्डवेयर को हार्डवेयर वर्चुअलाइजेशन मोड में प्रवेश करने का कारण बनता है जो रिंग 0 और रिंग 3 विशेषाधिकारों को दोहराता है।[1]

KVM के साथ, I/O वर्चुअलाइजेशन अधिकतर यूजर स्पेस में उस प्रक्रिया द्वारा किया जाता है जिसने VM बनाया है, जिसे VMM या हाइपरवाइजर कहा जाता है, पहले के हाइपरवाइजर के विपरीत जिसे आम तौर पर एक अलग हाइपरवाइजर प्रक्रिया की आवश्यकता होती थी [४१]। एक KVM हाइपरवाइजर प्रत्येक VM अतिथि को अपना स्वयं का मेमोरी क्षेत्र प्रदान करता है जो अतिथि बनाने वाली प्रक्रिया के मेमोरी क्षेत्र से अलग होता है। यह कर्नेल स्पेस के साथ-साथ यूजर स्पेस से बनाए गए अतिथियों के लिए भी सही है। प्रत्येक VM Linux होस्ट पर एक प्रक्रिया से मैप होता है और अतिथि को सौंपा गया प्रत्येक वर्चुअल CPU उस होस्ट प्रक्रिया में एक थ्रेड होता है। VM की यूजरस्पेस हाइपरवाइजर प्रक्रिया KVM को सिस्टम कॉल तभी करती है जब विशेषाधिकार प्राप्त निष्पादन की आवश्यकता होती है

2.2 सर्वर रहित क्लाउड कंप्यूटिंग

क्लाउड कंप्यूटिंग के लिए एक तेजी से लोकप्रिय मॉडल सर्वरलेस कंप्यूटिंग है, जिसमें CSP उपयोगकर्ता के कोड को चलाने वाले सर्वर की मापनीयता और उपलब्धता का प्रबंधन करता है। सर्वरलेस कंप्यूटिंग के एक कार्यान्वयन को फ़ंक्शन-एज़-ए-सर्विस (FaaS) कहा जाता है। इस मॉडल में, एक क्लाउड उपयोगकर्ता उन फ़ंक्शन को परिभाषित करता है जिन्हें सेवा प्रदाता के एप्लिकेशन प्रोग्रामिंग इंटरफ़ेस (API) के माध्यम से आवश्यक रूप से कॉल किया जाता है (इसलिए इसका नाम "फ़ंक्शन-एज़-ए-सर्विस" है) और CSP उस सर्वर पर संसाधन आवंटन का प्रबंधन करता है जो उपयोगकर्ता के फ़ंक्शन को निष्पादित करता है (इसलिए इसका नाम "सर्वरलेस कंप्यूटिंग" है - उपयोगकर्ता कोई सर्वर प्रबंधन नहीं करता है)। इसी तरह, कंटेनर-एज़-ए-सर्विस (CaaS) कंप्यूटिंग कंटेनर, पोर्टेबल रनटाइम पैकेज को मांग पर चलाता है। FaaS और CaaS का केंद्रीकृत सर्वर प्रबंधन CSP और उपयोगकर्ताओं दोनों के लिए आर्थिक रूप से आकर्षक है। CSP अपने उपयोगकर्ताओं के कार्यभार को अपनी इच्छानुसार प्रबंधित कर सकता है, न्यूनतम परिचालन लागत के लिए अनुकूलन कर सकता है, और लचीली कीमत लागू कर सकता है जहाँ उपयोगकर्ता निष्पादन समय के लिए भुगतान करते हैं। उपयोगकर्ता को सर्वर अवसंरचना डिजाइन या प्रबंधन के बारे में चिंता करने की आवश्यकता नहीं होती है, और इस प्रकार विकास लागत कम हो जाती है तथा रखरखाव लागत अपेक्षाकृत कम और पूर्वानुमानित दर पर CSP को आउटसोर्स हो जाती है।

2.3 माइक्रोवीएम और AWS फायरक्रैकर

FaaS और CaaS प्रदाता रनिंग फंक्शन और कंटेनर को मैनेज करने के लिए कई तरह के सिस्टम का इस्तेमाल करते हैं। Docker, Podman और LXD जैसे कंटेनर सिस्टम किसी भी वातावरण में सैंडबॉक्स किए गए एप्लिकेशन को पैकेज करने और चलाने के लिए एक सुविधाजनक और हल्का तरीका प्रदान करते हैं। हालाँकि, क्लाउड कंप्यूटिंग के कई पारंपरिक रूपों के लिए उपयोग की जाने वाली वर्चुअल मशीनों की तुलना में, कंटेनर कम अलगाव और इसलिए कम सुरक्षा प्रदान करते हैं। हाल के वर्षों में, प्रमुख CSP ने माइक्रोवीएम पेश किए हैं जो अतिरिक्त सुरक्षा के लिए हल्के वर्चुअलाइजेशन के साथ पारंपरिक कंटेनर का समर्थन करते हैं। [1, 55] KVM के साथ हार्डवेयर वर्चुअलाइजेशन की दक्षता और माइक्रोवीएम के हल्के डिजाइन का मतलब है कि वर्चुअलाइज्ड, कंटेनराइज्ड या कंटेनर जैसी प्रणालियों में कोड लगभग अनवर्चुअलाइज्ड कोड जितना तेज़ चल सकता है और पारंपरिक कंटेनर के बराबर ओवरहेड के साथ चल सकता है।

फायरक्रैकर [1] AWS द्वारा विकसित एक माइक्रोवीएम है जो AWS लैम्ब्डा FaaS और AWS Fargate CaaS वर्कलोड को अलग वीएम में अलग करता है। यह केवल x86 या ARM Linux-KVM होस्ट पर Linux मेहमानों का समर्थन करता है और सीमित संख्या में डिवाइस प्रदान करता है जो अतिथि सिस्टम के लिए उपलब्ध हैं। ये सीमाएँ फायरक्रैकर को अपने कोड बेस के आकार और चल रहे वीएम के लिए मेमोरी ओवरहेड में बहुत हल्का होने के साथ-साथ बूट या शट डाउन करने में बहुत तेज़ बनाती हैं। इसके अतिरिक्त, KVM का उपयोग फायरक्रैकर की आवश्यकताओं को हल्का करता है, क्योंकि कुछ वर्चुअलाइजेशन फ़ंक्शन कर्नेल सिस्टम कॉल द्वारा नियंत्रित किए जाते हैं और होस्ट OS मानक प्रक्रियाओं के रूप में VM का प्रबंधन करता है। रस्ट में लिखे गए अपने छोटे कोड बेस के कारण, फायरक्रैकर को बहुत सुरक्षित माना जाता है दिलचस्प बात यह है कि फायरक्रैकर श्वेत पत्र माइक्रोआर्किटेक्चरल हमलों को अपने हमलावर मॉडल के दायरे में घोषित करता है [1] लेकिन अतिथि और होस्ट कर्नेल के लिए सामान्य सुरक्षित सिस्टम कॉन्फ़िगरेशन अनुशंसाओं से परे माइक्रोआर्किटेक्चरल हमलों के खिलाफ विस्तृत सुरक्षा विश्लेषण या विशेष प्रतिवाद का अभाव है। फायरक्रैकर दस्तावेज़ सिस्टम सुरक्षा अनुशंसाएँ प्रदान करता है [8] जिसमें प्रतिवादों की एक विशिष्ट सूची शामिल है, जिसे हम अनुभाग 2.6.1 में शामिल करते हैं।

2.4 मेल्टडाउन और एमडीएस

2018 में, मेल्टडाउन [32] हमले ने दिखाया कि सट्टा रूप से एक्सेस किए गए डेटा को कैश साइड-चैनल में एन्कोड करके सुरक्षा सीमाओं के पार निकाला जा सकता है। इसने जल्द ही इसी तरह के हमलों की एक पूरी श्रेणी को जन्म दिया, जिसे माइक्रोआर्किटेक्चरल डेटा सैंपलिंग (एमडीएस) के रूप में जाना जाता है, जिसमें फ़ॉलआउट [14], दुष्ट इन-फ़्लाइट डेटा लोड (आरआईडीएल) [50], टीएसएक्स एसिंक्रोनस एबॉर्ट (टीएए) [50] और ज़ोम्बीलोड [46] शामिल हैं। ये सभी हमले सट्टा निष्पादन का फायदा उठाने के लिए एक ही सामान्य पैटर्न का पालन करते हैं:

(1) पीड़ित एक प्रोग्राम चलाता है जो गुप्त डेटा को संभालता है, और गुप्त डेटा कैश या सीपीयू बफर से गुजरता है।

(2) हमलावर एक विशेष रूप से चुने गए निर्देश को चलाता है जिससे CPU को गलती से यह अनुमान लग जाता है कि गुप्त डेटा की आवश्यकता होगी। CPU गुप्त डेटा को हमलावर के निर्देश पर अग्रेषित करता है।

(3) अग्रेषित गुप्त डेटा का उपयोग उस सरणी में पढ़ी गई मेमोरी के लिए सूचकांक के रूप में किया जाता है, जिसे हमलावर एक्सेस करने के लिए अधिकृत होता है, जिससे उस सरणी की एक विशेष पंक्ति कैश हो जाती है।

(4) सीपीयू डेटा की जाँच पूरी कर लेता है और यह निर्णय लेता है कि गुप्त डेटा गलत तरीके से अग्रेषित किया गया था, और निष्पादन स्थिति को अग्रेषित किए जाने से पहले की स्थिति में वापस कर देता है, लेकिन कैश की स्थिति वापस नहीं आती है। (5) हमलावर यह देखने के लिए पूरे सरणी की जाँच करता है कि कौन सी लाइन कैश की गई थी; उस लाइन का सूचकांक गुप्त डेटा का मान है।

मूल मेल्टडाउन भेद्यता ने कैश फ़ॉरवर्डिंग को लक्षित किया और कैश में मौजूद किसी भी मेमोरी पते से इस तरीके से डेटा निष्कर्षण की अनुमति दी। MDS हमले ऑन-कोर माइक्रोआर्किटेक्चर में छोटे और अधिक विशिष्ट बफ़र्स को लक्षित करते हैं, और इसलिए हमलों का एक संबंधित लेकिन अलग वर्ग बनाते हैं जिन्हें काफी अलग तरीके से कम किया जाता है। जबकि मेल्टडाउन मुख्य मेमोरी को लक्षित करता है जिसे अपेक्षाकृत कम बार अपडेट किया जाता है और सभी कोर, थ्रेड और प्रक्रियाओं में साझा किया जाता है, MDS हमले उन बफ़र्स को लक्षित करते हैं जो कोर के लिए स्थानीय होते हैं (हालांकि कभी-कभी थ्रेड में साझा किए जाते हैं) और निष्पादन के दौरान अधिक बार अपडेट किए जाते हैं।

2.4.1 मूल MDS वैरिएंट । चित्र 1 इंटेल CPU पर प्रमुख ज्ञात MDS हमले के मार्गों को दर्शाता है और इंटेल तथा उन्हें रिपोर्ट करने वाले शोधकर्ताओं द्वारा विभिन्न वैरिएंट को दिए गए नामों को दर्शाता है। सबसे व्यापक रूप से, इंटेल अपने CPU में MDS कमजोरियों को उस विशिष्ट बफर के आधार पर वर्गीकृत करता है, जिससे डेटा को सट्टा रूप से अग्रेषित किया जाता है, क्योंकि इन बफर्स का उपयोग कई अलग-अलग ऑपरेशनों के लिए किया जाता है। RIDL MDS कमजोरियों को CPU के लोड पोर्ट से लीक होने वाले वैरिएंट के लिए माइक्रोआर्किटेक्चरल लोड पोर्ट डेटा सैंपलिंग (MLPDS) और CPU के LFB से लीक होने वाले वैरिएंट के लिए माइक्रोआर्किटेक्चरल फिल बफर डेटा सैंपलिंग (MFBDS) के रूप में वर्गीकृत किया जा सकता है। इसी तरह, इंटेल फ़ॉलआउट भेद्यता को माइक्रोआर्किटेक्चरल स्टोर बफर डेटा सैंपलिंग (MSBDS) कहता है, क्योंकि इसमें स्टोर बफर से रिसाव शामिल है। वेक्टर रजिस्टर सैंपलिंग (VRS) MSBDS का एक वैरिएंट है जो स्टोर बफर से गुज़रने के दौरान वेक्टर ऑपरेशन द्वारा संभाले जाने वाले डेटा को लक्षित करता है। VERW बाईपास एक बग का फायदा उठाता है

MFBDS के लिए माइक्रोकोड फ़िक्स जो पुराने और संभावित रूप से गुप्त डेटा को LFB में लोड करता है। रिसाव का मूल तंत्र समान है, और VERW बाईपास को MFBDS का एक विशेष मामला माना जा सकता है। L1 डेटा इविक्शन सैंपलिंग (L1DES) MFBDS का एक और विशेष मामला है, जहाँ L1 डेटा कैश से निकाला गया डेटा LFB से होकर गुजरता है और MDS हमले के लिए असुरक्षित हो जाता है। विशेष रूप से, L1DES एक ऐसा मामला है जहाँ हमलावर वास्तव में CPU में गुप्त डेटा की उपस्थिति को ट्रिगर कर सकता है (इसे निकालकर), जबकि अन्य MDS हमले सीधे पीड़ित प्रक्रिया पर निर्भर करते हैं जो गुप्त डेटा को सही CPU बफर में लाने के लिए एक्सेस करता है।

2.4.2 मेडुसा। मेडुसा [37] इंटेल द्वारा MLPDS वेरिएंट [25] के रूप में वर्गीकृत MDS हमलों की एक श्रेणी है। मेडुसा भेद्यताएँ इंटेल प्रोसेसर के राइट-कम्बाइन (WC) बफर में स्टोर को सट्टा रूप से संयोजित करने के लिए उपयोग किए जाने वाले अपूर्ण पैटर्न-मिलान एल्गोरिदम का फायदा उठाती हैं। इंटेल WC बफर को लोड पोर्ट का हिस्सा मानता है, इसलिए इंटेल इस भेद्यता को MLPDS के मामले के रूप में वर्गीकृत करता है। मेडुसा के तीन ज्ञात वेरिएंट हैं जो सट्टा रिसाव का कारण बनने के लिए राइट-कम्बाइन बफर की एक अलग विशेषता का फायदा उठाते हैं:

कैश इंडेक्सिंग: दोषपूर्ण लोड को अनुमानित रूप से एक मेल खाते कैश लाइन ऑफसेट के साथ पहले के लोड के साथ जोड़ा जाता है।

असंरेखित स्टोर-टू-लोड अग्रेषण: एक वैध स्टोर के बाद एक आश्रित लोड जो एक गलत संरेखित मेमोरी दोष को ट्रिगर करता है, WC से यादृच्छिक डेटा को अग्रेषित करने का कारण बनता है।

छाया REP MOV : एक दोषपूर्ण REP MOV निर्देश के बाद एक आश्रित लोड एक अलग REP MOV का डेटा लीक करता है।

2.4.3 TSX एसिंक्रोनस एबॉर्ट। हार्डवेयर भेद्यता TSX एसिंक्रोनस एबॉर्ट (TAA) [24] MDS हमले को अंजाम देने के लिए एक अलग अटकलबाजी तंत्र प्रदान करता है। जबकि मानक MDS हमले एक मानक अटकलबाजी निष्पादन के साथ प्रतिबंधित डेटा तक पहुँचते हैं, TAA TSX द्वारा कार्यान्वित किए गए परमाणु मेमोरी लेनदेन का उपयोग करता है। जब एक परमाणु मेमोरी लेनदेन एक एसिंक्रोनस एबॉर्ट का सामना करता है, उदाहरण के लिए क्योंकि कोई अन्य प्रक्रिया लेनदेन द्वारा उपयोग के लिए चिह्नित कैश लाइन पढ़ती है या क्योंकि लेनदेन में कोई दोष आता है, तो लेनदेन में सभी ऑपरेशन लेनदेन शुरू होने से पहले आर्किटेक्चरल स्थिति में वापस आ जाते हैं। हालाँकि, इस रोलबैक के दौरान, लेनदेन के अंदर के निर्देश जो पहले से ही निष्पादन शुरू कर चुके हैं, वे अटकलबाजी निष्पादन जारी रख सकते हैं, जैसा कि अन्य MDS हमलों के चरण (2) और (3) में होता है। TAA उन सभी Intel प्रोसेसर को प्रभावित करता है जो TSX का समर्थन करते हैं, और कुछ नए प्रोसेसर के मामले में जो अन्य MDS हमलों से प्रभावित नहीं होते हैं, MDS शमन या TAA-विशिष्ट शमन (जैसे TSX को अक्षम करना) को TAA [24] से बचाने के लिए सॉफ़्टवेयर में लागू किया जाना चाहिए।

2.4.4 शमन। यद्यपि मेल्टडाउन और एमडीएस-श्रेणी की कमजोरियाँ निम्न स्तर के माइक्रोआर्किटेक्चरल ऑपरेशनों का फायदा उठाती हैं , लेकिन उन्हें सबसे कमजोर सीपीयू पर माइक्रोकोड फर्मवेयर पैच के साथ कम किया जा सकता है।

पेज टेबल आइसोलेशन। ऐतिहासिक रूप से, कर्नेल पेज टेबल को यूजर-लेवल प्रोसेस पेज टेबल में शामिल किया गया है ताकि यूजर-लेवल प्रोसेस कम से कम ओवरहेड के साथ कर्नेल को सिस्टम कॉल कर सके। पेज टेबल आइसोलेशन (पहली बार ग्रस एट अल द्वारा KAISER [19] के रूप में प्रस्तावित) यूजर पेज टेबल में केवल न्यूनतम आवश्यक कर्नेल मेमोरी को मैप करता है और एक दूसरी पेज टेबल पेश करता है जिसे केवल कर्नेल द्वारा एक्सेस किया जा सकता है। उपयोगकर्ता प्रक्रिया कर्नेल पेज टेबल तक पहुँचने में असमर्थ होने के कारण, कर्नेल मेमोरी के एक छोटे और विशेष रूप से चुने गए अंश को छोड़कर सभी तक पहुँच को निचले स्तर के कैश तक पहुँचने से पहले रोक दिया जाता है जहाँ मेल्टडाउन हमला शुरू होता है।

बफर ओवरराइट। MDS हमले जो ऑन-कोर CPU बफर को लक्षित करते हैं, उन्हें निचले स्तर और अधिक लक्षित बचाव की आवश्यकता होती है। इंटेल ने एक माइक्रोकोड अपडेट पेश किया जो पहले स्तर के डेटा (L1d) कैश (कैश टाइमिंग साइडचैनल हमलों का एक सामान्य लक्ष्य) को फ्लश करने या VERW निर्देश चलाने पर कमजोर बफर को ओवरराइट करता है [25]। कर्नेल तब अविश्वसनीय प्रक्रिया पर स्विच करते समय बफर ओवरराइट को ट्रिगर करके MDS हमलों से सुरक्षा कर सकता है।

बफर ओवरराइट शमन एमडीएस हमलों को उनके स्रोत पर लक्षित करता है, लेकिन कम से कम कहने के लिए अपूर्ण है। एसएमटी सक्षम होने पर प्रक्रियाएँ एक ही कोर पर समवर्ती रूप से चलने वाले थ्रेड्स से हमलों के लिए असुरक्षित रहती हैं (चूँकि दोनों थ्रेड्स सक्रिय प्रक्रिया को वास्तव में बदले बिना असुरक्षित बफ़र्स को साझा करते हैं), इसके अलावा, मूल बफर ओवरराइट माइक्रोकोड अपडेट के तुरंत बाद, आरआईडीएल टीम ने पाया कि कुछ स्काईलेक सीपीयू पर, बफ़र्स को पुराने और संभावित रूप से संवेदनशील डेटा के साथ ओवरराइट किया गया था [50], और शमन सक्षम और एसएमटी अक्षम होने पर भी असुरक्षित बने रहे। फिर भी अन्य प्रोसेसर टीएए के लिए असुरक्षित हैं, लेकिन नॉनटीएए एमडीएस हमलों के लिए नहीं, और उन्हें बफर ओवरराइट माइक्रोकोड अपडेट प्राप्त नहीं हुआ और इस तरह एमडीएस हमलों को रोकने के लिए टीएसएक्स को पूरी तरह से अक्षम करने की आवश्यकता होती है [20, 24]।

2.5 स्पेक्ट्रे

2018 में, जान हॉर्न और पॉल कोचर [30] ने स्वतंत्र रूप से पहले स्पेक्ट्रे वेरिएंट की रिपोर्ट की। तब से, कई अलग-अलग स्पेक्ट्रे वेरिएंट [22, 30, 31, 33] और सब-वेरिएंट [10, 13, 16, 28, 52] खोजे गए हैं। स्पेक्ट्रे हमले सीपीयू को आर्किटेक्चरल रूप से दुर्गम मेमोरी तक पहुंचने देते हैं और आर्किटेक्चरल स्टेट में डेटा लीक करते हैं। इसलिए, सभी स्पेक्ट्रे वेरिएंट में तीन घटक होते हैं [27]:

पहला घटक स्पेक्ट्रे गैजेट है जिसे अनुमानित रूप से निष्पादित किया जाता है। स्पेक्ट्रे वेरिएंट आमतौर पर उनके द्वारा शोषण की गई गलत भविष्यवाणी के स्रोत से अलग होते हैं। एक सशर्त प्रत्यक्ष शाखा का परिणाम, उदाहरण के लिए, पैटर्न इतिहास तालिका (PHT) द्वारा भविष्यवाणी की जाती है। PHT की गलत भविष्यवाणी लोड और स्टोर निर्देशों के लिए एक अनुमानित सीमा जांच बाईपास की ओर ले जा सकती है [13, 28, 30]। एक अप्रत्यक्ष कूद का शाखा लक्ष्य शाखा लक्ष्य बफर (BTB) द्वारा अनुमानित किया जाता है। यदि कोई हमलावर BTB की गलत भविष्यवाणी के परिणाम को प्रभावित कर सकता है, तो अनुमानित रिटर्न-उन्मुख प्रोग्रामिंग हमले संभव हैं [10, 13, 16, 30]। रिटर्न स्टैक बफर (RSB) द्वारा की गई भविष्यवाणियों के लिए भी यही सच है स्पेक्ट्रे हमलों का एक अन्य स्रोत स्टोर-टू-लोड निर्भरताओं की भविष्यवाणी है। यदि किसी लोड को पिछले स्टोर पर निर्भर न होने के लिए गलत तरीके से भविष्यवाणी की जाती है, तो यह सट्टा रूप से बासी डेटा पर निष्पादित होता है जो सट्टा स्टोर बाईपास [22] की ओर ले जा सकता है। ये सभी गैजेट डिफ़ॉल्ट रूप से शोषक नहीं हैं, लेकिन अब चर्चा किए गए अन्य दो घटकों पर निर्भर हैं।

दूसरा घटक यह है कि हमलावर उपर्युक्त गैजेट के इनपुट को कैसे नियंत्रित करता है। हमलावर उपयोगकर्ता इनपुट, फ़ाइल सामग्री, नेटवर्क पैकेट या अन्य आर्किटेक्चरल तंत्र के माध्यम से सीधे गैजेट इनपुट मानों को परिभाषित करने में सक्षम हो सकते हैं। दूसरी ओर हमलावर लोड वैल्यू इंजेक्शन [12] या फ्लोटिंग पॉइंट वैल्यू इंजेक्शन [42] के माध्यम से गैजेट में डेटा को अस्थायी रूप से इंजेक्ट करने में सक्षम हो सकते हैं। हमलावर गैजेट इनपुट को सफलतापूर्वक नियंत्रित करने में सक्षम होते हैं यदि वे प्रभावित कर सकते हैं कि अटकलें विंडो के दौरान कौन से डेटा या निर्देश एक्सेस या निष्पादित किए जाते हैं।

तीसरा घटक गुप्त चैनल है जिसका उपयोग सट्टा माइक्रोआर्किटेक्चरल स्थिति को आर्किटेक्चरल स्थिति में स्थानांतरित करने के लिए किया जाता है और इसलिए सट्टा रूप से एक्सेस किए गए डेटा को एक स्थायी वातावरण में बाहर निकालता है। कैश गुप्त चैनल [39, 40, 54] लागू होते हैं यदि पीड़ित कोड सट्टा रूप से एक्सेस किए गए गुप्त डेटा [30] के आधार पर क्षणिक मेमोरी एक्सेस करता है। यदि किसी रहस्य को सट्टा रूप से एक्सेस किया जाता है और ऑन-कोर बफर में लोड किया जाता है, तो हमलावर एक्सफ़िल्टर्ड डेटा को हमलावर थ्रेड पर क्षणिक रूप से स्थानांतरित करने के लिए एमडीएस-आधारित चैनल [14, 46, 50] पर भरोसा कर सकता है जहां डेटा को आर्किटेक्चरल स्थिति में स्थानांतरित किया जाता है, उदाहरण के लिए, कैश गुप्त चैनल के माध्यम से। अंतिम लेकिन कम से कम नहीं, यदि पीड़ित गुप्त डेटा के आधार पर कोड निष्पादित करता है

2.5.1 शमन। विभिन्न स्पेक्ट्रे वेरिएंट को कम करने के लिए कई प्रतिवाद विकसित किए गए थे। यदि तीन आवश्यक घटकों में से एक को हटा दिया जाता है, तो एक विशिष्ट स्पेक्ट्रे वेरिएंट प्रभावी रूप से अक्षम हो जाता है। स्पेक्ट्रे गैजेट के इनपुट पर नियंत्रण के बिना एक हमलावर द्वारा सफलतापूर्वक हमला शुरू करने की संभावना नहीं है। यदि सट्टा स्थिति को आर्किटेक्चरल स्थिति में बदलने के लिए एक गुप्त चैनल उपलब्ध नहीं है, तो भी यही सच है। लेकिन चूंकि यह आमतौर पर गारंटी देना मुश्किल होता है, इसलिए स्पेक्ट्रे प्रतिवाद मुख्य रूप से गलत पूर्वानुमानों को रोकने पर ध्यान केंद्रित करते हैं। महत्वपूर्ण कोड अनुभागों से पहले lfence निर्देश डालने से इस बिंदु से परे सट्टा निष्पादन अक्षम हो जाता है और इसलिए इसे एक सामान्य प्रतिवाद के रूप में उपयोग किया जा सकता है। लेकिन इसके उच्च प्रदर्शन ओवरहेड के कारण, अधिक विशिष्ट प्रतिवाद विकसित किए गए थे। स्पेक्ट्रे-बीटीबी प्रतिवाद में रेटपोलिन [48] और आईबीआरएस, एसटीआईबीपी, या आईबीपीबी [23] जैसे माइक्रोकोड अपडेट शामिल हैं। स्पेक्ट्रे-आरएसबी और स्पेक्ट्रे-बीटीबी-वाया-आरएसबी को दुर्भावनापूर्ण प्रविष्टियों को अधिलेखित करने और आरएसबी को अंडरफ़्लो होने से रोकने के लिए आरएसबी को मानों से भरकर या आईबीआरएस माइक्रोकोड अपडेट स्थापित करके कम किया जा सकता है। स्पेक्ट्रे-एसटीएल को एसएसबीडी माइक्रोकोड अपडेट [23] द्वारा कम किया जा सकता है। हमलावर को साझा शाखा भविष्यवाणी बफ़र्स के साथ छेड़छाड़ करने से रोकने के लिए एक और कठोर विकल्प एसएमटी को अक्षम करना है। एसएमटी को अक्षम करना एक महत्वपूर्ण प्रदर्शन हानि की कीमत पर समवर्ती किरायेदारों के बीच शाखा भविष्यवाणी हार्डवेयर संसाधनों को प्रभावी ढंग से विभाजित करता है।

2.6 AWS का आइसोलेशन मॉडल

फायरक्रैकर को खास तौर पर सर्वरलेस और कंटेनर एप्लीकेशन [1] के लिए बनाया गया है और वर्तमान में इसका इस्तेमाल AWS के Fargate CaaS और Lambda FaaS द्वारा किया जाता है। इन दोनों सर्विस मॉडल में, फायरक्रैकर प्राथमिक आइसोलेशन सिस्टम है जो हर व्यक्तिगत Fargate टास्क या Lambda इवेंट को सपोर्ट करता है। इन दोनों सर्विस मॉडल को अपेक्षाकृत छोटे और अल्पकालिक टास्क की बहुत अधिक संख्या को चलाने के लिए भी डिज़ाइन किया गया है। AWS आइसोलेशन सिस्टम के लिए डिज़ाइन आवश्यकताओं को सूचीबद्ध करता है जो अंततः फायरक्रैकर बन गया:

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

ओवरहेड और घनत्व: एक ही मशीन पर हजारों कार्यों को न्यूनतम अपव्यय के साथ चलाना संभव होना चाहिए।

प्रदर्शन: फ़ंक्शन को मूल रूप से चलने के समान ही प्रदर्शन करना चाहिए। प्रदर्शन भी सुसंगत होना चाहिए, और समान हार्डवेयर पर पड़ोसियों के व्यवहार से अलग होना चाहिए।

संगतता : लैम्ब्डा फ़ंक्शन को मनमाने ढंग से लिनक्स बाइनरी और लाइब्रेरीज़ रखने की अनुमति देता है। इन्हें कोड में बदलाव या पुनर्संकलन के बिना समर्थित होना चाहिए।

तीव्र स्विचिंग: नए कार्यों को शीघ्रता से शुरू करना और पुराने कार्यों को साफ करना संभव होना चाहिए।

सॉफ्ट आवंटन: सीपीयू, मेमोरी और अन्य संसाधनों को अधिक प्रतिबद्ध करना संभव होना चाहिए, जिसमें प्रत्येक फ़ंक्शन केवल उन संसाधनों का उपभोग करता है जिनकी उसे आवश्यकता है, न कि उन संसाधनों का जिनके वह हकदार है। [1]

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

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

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

2.6.1 फायरक्रैकर सुरक्षा अनुशंसाएँ। फायरक्रैकर दस्तावेज़ माइक्रोआर्किटेक्चरल साइड-चैनल [8] से सुरक्षा के लिए निम्नलिखित सावधानियों की भी अनुशंसा करता है:

• एसएमटी अक्षम करें

• कर्नेल पृष्ठ-तालिका अलगाव सक्षम करें

• कर्नेल केम-पेज मर्जिंग अक्षम करें

• स्पेक्ट्रे-बीटीबी शमन (जैसे, x86 पर आईबीआरएस और आईबीपीबी) के साथ संकलित कर्नेल का उपयोग करें

• स्पेक्ट्रे-पीएचटी शमन सत्यापित करें

• L1TF शमन सक्षम करें • स्पेक्ट्रे-एसटीएल शमन सक्षम करें

• रोहैमर शमन के साथ मेमोरी का उपयोग करें

• स्वैप अक्षम करें या सुरक्षित स्वैप का उपयोग करें

[1] वर्चुअलाइज्ड रिंग 0 और रिंग 3 मुख्य कारणों में से एक हैं, जिनके कारण निकट-मूल कोड निष्पादन प्राप्त किया जाता है।