एवीएफ वास्तुकला

एंड्रॉइड वर्चुअलाइजेशन फ्रेमवर्क को लागू करने के लिए आवश्यक सभी घटकों का संदर्भ कार्यान्वयन प्रदान करता है। वर्तमान में यह कार्यान्वयन ARM64 तक सीमित है। यह पृष्ठ ढांचे की वास्तुकला की व्याख्या करता है।

पृष्ठभूमि

आर्म आर्किटेक्चर चार अपवाद स्तरों तक की अनुमति देता है, जिसमें अपवाद स्तर 0 (EL0) सबसे कम विशेषाधिकार प्राप्त है, और अपवाद स्तर 3 (EL3) सबसे अधिक है। Android कोडबेस का सबसे बड़ा हिस्सा (सभी यूज़रस्पेस घटक) EL0 पर चलता है। बाकी जिसे आमतौर पर "एंड्रॉइड" कहा जाता है, वह लिनक्स कर्नेल है, जो ईएल1 पर चलता है।

EL2 परत एक हाइपरविजर की शुरूआत की अनुमति देती है जो मजबूत गोपनीयता और अखंडता की गारंटी के साथ EL1/EL0 पर अलग-अलग pVMs में मेमोरी और उपकरणों को अलग करने में सक्षम बनाती है।

सूत्र

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

KVM/arm64, वर्चुअलाइजेशन होस्ट एक्सटेंशन (VHE) (ARMv8.1 और बाद के संस्करण) जैसे कुछ CPU सुविधाओं की उपलब्धता के आधार पर विभिन्न निष्पादन मोड का समर्थन करता है। इनमें से एक मोड में, जिसे आमतौर पर गैर-वीएचई मोड के रूप में जाना जाता है, हाइपरविजर कोड बूट के दौरान कर्नेल छवि से अलग हो जाता है और ईएल2 पर स्थापित होता है, जबकि कर्नेल स्वयं ईएल1 पर चलता है। हालांकि लिनक्स कोडबेस का हिस्सा, KVM का EL2 घटक कई EL1s के बीच स्विच का प्रभारी एक छोटा घटक है, और पूरी तरह से होस्ट के कर्नेल द्वारा नियंत्रित होता है। हाइपरविजर घटक लिनक्स के साथ संकलित है, लेकिन vmlinux छवि के एक अलग, समर्पित स्मृति खंड में रहता है। pKVM नई सुविधाओं के साथ हाइपरवाइजर कोड का विस्तार करके इस डिजाइन का लाभ उठाता है, जिससे यह Android होस्ट कर्नेल और उपयोगकर्ता स्थान पर प्रतिबंध लगा सकता है, और अतिथि मेमोरी और हाइपरविजर तक होस्ट पहुंच को सीमित कर सकता है।

बूट प्रक्रिया

pKVM बूट प्रक्रिया को चित्र 1 में दर्शाया गया है। बूटलोडर के लिए पहला चरण EL2 पर pKVM-सक्षम Linux कर्नेल में प्रवेश करना है। प्रारंभिक बूट के दौरान, कर्नेल पता लगाता है कि यह EL2 पर चल रहा है, खुद को EL1 से वंचित करता है, pKVM को पीछे छोड़ता है। इस बिंदु से, लिनक्स कर्नेल सामान्य रूप से बूट करने के लिए आगे बढ़ता है, उपयोगकर्ता स्थान तक पहुंचने तक सभी आवश्यक डिवाइस ड्राइवरों को लोड करता है। ये चरण pKVM के नियंत्रण में होते हैं।

बूट प्रक्रिया केवल शुरुआती बूट के दौरान कर्नेल छवि की अखंडता को बनाए रखने के लिए बूटलोडर पर भरोसा करती है। जब कर्नेल को वंचित किया जाता है, तो इसे अब हाइपरविजर द्वारा विश्वसनीय नहीं माना जाता है, जो कर्नेल से समझौता होने पर भी खुद को बचाने के लिए जिम्मेदार होता है।

pKVM बूट प्रक्रिया

चित्र 1. pKVM बूट प्रक्रिया

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

इसके अलावा, Android पारिस्थितिकी तंत्र में GKI को अपनाने से स्वचालित रूप से pKVM हाइपरविजर को कर्नेल के समान बाइनरी में Android उपकरणों पर तैनात करने की अनुमति मिलती है।

सीपीयू मेमोरी एक्सेस सुरक्षा

आर्म आर्किटेक्चर एक मेमोरी मैनेजमेंट यूनिट (MMU) को दो स्वतंत्र चरणों में विभाजित करता है, दोनों का उपयोग मेमोरी के विभिन्न भागों में एड्रेस ट्रांसलेशन और एक्सेस कंट्रोल को लागू करने के लिए किया जा सकता है। चरण 1 MMU को EL1 द्वारा नियंत्रित किया जाता है और पहले स्तर के एड्रेस ट्रांसलेशन की अनुमति देता है। चरण 1 MMU का उपयोग लिनक्स द्वारा प्रत्येक यूजरस्पेस प्रक्रिया और अपने स्वयं के वर्चुअल एड्रेस स्पेस को प्रदान किए गए वर्चुअल एड्रेस स्पेस को प्रबंधित करने के लिए किया जाता है।

चरण 2 एमएमयू ईएल2 द्वारा नियंत्रित होता है और चरण 1 एमएमयू के आउटपुट पते पर दूसरे पते के अनुवाद के आवेदन को सक्षम बनाता है, जिसके परिणामस्वरूप भौतिक पता (पीए) होता है। चरण 2 अनुवाद का उपयोग हाइपरवाइजर द्वारा सभी अतिथि वीएम से मेमोरी एक्सेस को नियंत्रित और अनुवाद करने के लिए किया जा सकता है। जैसा कि चित्र 2 में दिखाया गया है, जब अनुवाद के दोनों चरण सक्षम होते हैं, तो चरण 1 के आउटपुट पते को मध्यवर्ती भौतिक पता (IPA) कहा जाता है। नोट: आभासी पता (VA) को IPA और फिर PA में अनुवादित किया जाता है।

सीपीयू मेमोरी एक्सेस सुरक्षा

चित्रा 2. सीपीयू मेमोरी एक्सेस सुरक्षा

ऐतिहासिक रूप से, KVM अतिथि चलाते समय चरण 2 अनुवाद सक्षम के साथ चलता है और होस्ट Linux कर्नेल चलाते समय चरण 2 अक्षम होता है। यह आर्किटेक्चर होस्ट स्टेज 1 MMU से मेमोरी एक्सेस को स्टेज 2 MMU से गुजरने की अनुमति देता है, इसलिए होस्ट से गेस्ट मेमोरी पेजों तक अप्रतिबंधित एक्सेस की अनुमति देता है। दूसरी ओर, pKVM होस्ट संदर्भ में भी स्टेज 2 सुरक्षा को सक्षम करता है, और हाइपरविजर को होस्ट के बजाय अतिथि मेमोरी पेजों की सुरक्षा के लिए प्रभारी रखता है।

केवीएम मेहमानों के लिए जटिल आईपीए/पीए मैपिंग को लागू करने के लिए चरण 2 में एड्रेस ट्रांसलेशन का पूरा उपयोग करता है, जो भौतिक विखंडन के बावजूद मेहमानों के लिए सन्निहित स्मृति का भ्रम पैदा करता है। हालाँकि, होस्ट के लिए स्टेज 2 MMU का उपयोग केवल अभिगम नियंत्रण तक ही सीमित है। होस्ट स्टेज 2 आइडेंटिटी-मैप्ड है, यह सुनिश्चित करता है कि होस्ट आईपीए स्पेस में सन्निहित मेमोरी पीए स्पेस में सन्निहित है। यह आर्किटेक्चर पेज टेबल में बड़े मैपिंग के उपयोग की अनुमति देता है और इसके परिणामस्वरूप ट्रांसलेशन लुकसाइड बफर (टीएलबी) पर दबाव कम करता है। क्योंकि एक पहचान मानचित्रण पीए द्वारा अनुक्रमित किया जा सकता है, मेजबान चरण 2 का उपयोग सीधे पृष्ठ तालिका में पृष्ठ स्वामित्व को ट्रैक करने के लिए भी किया जाता है।

डायरेक्ट मेमोरी एक्सेस (डीएमए) सुरक्षा

जैसा कि पहले बताया गया है, सीपीयू पेज टेबल में लिनक्स होस्ट से गेस्ट पेजों को अनमैप करना अतिथि मेमोरी की सुरक्षा के लिए एक आवश्यक लेकिन अपर्याप्त कदम है। pKVM को मेजबान कर्नेल के नियंत्रण के तहत डीएमए-सक्षम उपकरणों द्वारा किए गए मेमोरी एक्सेस और दुर्भावनापूर्ण होस्ट द्वारा शुरू किए गए डीएमए हमले की संभावना से भी बचाने की जरूरत है। इस तरह के उपकरण को अतिथि मेमोरी तक पहुँचने से रोकने के लिए, pKVM को सिस्टम में प्रत्येक DMA-सक्षम डिवाइस के लिए इनपुट-आउटपुट मेमोरी मैनेजमेंट यूनिट (IOMMU) हार्डवेयर की आवश्यकता होती है, जैसा कि चित्र 3 में दिखाया गया है।

डीएमए मेमोरी एक्सेस सुरक्षा

चित्रा 3. डीएमए मेमोरी एक्सेस सुरक्षा

कम से कम, IOMMU हार्डवेयर पृष्ठ ग्रैन्युलैरिटी पर भौतिक मेमोरी के लिए डिवाइस को पढ़ने/लिखने की पहुंच प्रदान करने और रद्द करने का साधन प्रदान करता है। हालाँकि, यह IOMMU हार्डवेयर pVMs में उपकरणों के उपयोग को सीमित करता है क्योंकि वे पहचान-मैप किए गए चरण 2 को मानते हैं।

आभासी मशीनों के बीच अलगाव सुनिश्चित करने के लिए, विभिन्न संस्थाओं की ओर से उत्पन्न स्मृति लेनदेन IOMMU द्वारा अलग-अलग होने चाहिए ताकि अनुवाद के लिए पृष्ठ तालिकाओं के उपयुक्त सेट का उपयोग किया जा सके।

इसके अलावा, ईएल2 पर एसओसी-विशिष्ट कोड की मात्रा को कम करना पीकेवीएम के समग्र विश्वसनीय कंप्यूटिंग बेस (टीसीबी) को कम करने के लिए एक महत्वपूर्ण रणनीति है और हाइपरविजर में आईओएमएमयू ड्राइवरों को शामिल करने के लिए काउंटर चलाता है। इस समस्या को कम करने के लिए, EL1 पर होस्ट सहायक IOMMU प्रबंधन कार्यों के लिए ज़िम्मेदार है, जैसे कि बिजली प्रबंधन, आरंभीकरण और, जहाँ उपयुक्त हो, बाधा प्रबंधन।

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

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

स्मृति स्वामित्व

बूट समय पर, सभी गैर-हाइपरविजर मेमोरी को होस्ट के स्वामित्व में माना जाता है, और हाइपरवाइजर द्वारा ट्रैक किया जाता है। जब एक pVM उत्पन्न होता है, तो होस्ट इसे बूट करने की अनुमति देने के लिए मेमोरी पेज दान करता है और हाइपरविजर उन पेजों के स्वामित्व को होस्ट से pVM में स्थानांतरित कर देता है। इस प्रकार, हाइपरविजर मेजबान के चरण 2 पृष्ठ तालिका में पहुंच-नियंत्रण प्रतिबंधों को फिर से पृष्ठों तक पहुंचने से रोकने के लिए रखता है, अतिथि को गोपनीयता प्रदान करता है।

मेजबान और मेहमानों के बीच संचार उनके बीच नियंत्रित स्मृति साझाकरण से संभव होता है। मेहमानों को अपने कुछ पेजों को हाइपरकॉल का उपयोग करके होस्ट के साथ वापस साझा करने की अनुमति है, जो हाइपरवाइजर को उन पेजों को होस्ट स्टेज 2 पेज टेबल में रीमैप करने का निर्देश देता है। इसी तरह, ट्रस्टज़ोन के साथ होस्ट का संचार मेमोरी शेयरिंग और/या लेंडिंग ऑपरेशंस द्वारा संभव बनाया गया है, जिनमें से सभी को फर्मवेयर फ्रेमवर्क फॉर आर्म (FF-A) विनिर्देशन का उपयोग करके pKVM द्वारा बारीकी से मॉनिटर और नियंत्रित किया जाता है।

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

होस्ट को यह सुनिश्चित करना चाहिए कि वह उन पेजों तक पहुँचने का प्रयास नहीं करता है जिन्हें हाइपरविजर द्वारा एक्सेस करने योग्य नहीं बनाया गया है। एक अवैध होस्ट एक्सेस हाइपरविजर द्वारा होस्ट में एक सिंक्रोनस अपवाद को इंजेक्ट करने का कारण बनता है, जिसके परिणामस्वरूप या तो जिम्मेदार यूजरस्पेस टास्क को SEGV सिग्नल प्राप्त हो सकता है, या होस्ट कर्नेल क्रैश हो सकता है। आकस्मिक पहुंच को रोकने के लिए, मेहमानों को दान किए गए पृष्ठों को मेजबान कर्नेल द्वारा अदला-बदली या विलय के लिए अपात्र बना दिया जाता है।

इंटरप्ट हैंडलिंग और टाइमर

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

pKVM मौजूदा KVM कोड पर आधारित एक पूर्ण जेनेरिक इंटरप्ट कंट्रोलर वर्जन 3 (GICv3) इम्यूलेशन प्रदान करता है। इस अविश्वसनीय अनुकरण कोड के भाग के रूप में टाइमर और आईपीआई को नियंत्रित किया जाता है।

GICv3 समर्थन

EL1 और EL2 के बीच के इंटरफेस को यह सुनिश्चित करना चाहिए कि इंटरप्ट से संबंधित हाइपरविजर रजिस्टरों की प्रतियों सहित EL1 होस्ट को पूर्ण व्यवधान स्थिति दिखाई दे। यह दृश्यता आम तौर पर साझा मेमोरी क्षेत्रों, प्रति वर्चुअल सीपीयू (वीसीपीयू) का उपयोग करके हासिल की जाती है।

सिस्टम रजिस्टर रनटाइम सपोर्ट कोड को केवल सॉफ्टवेयर जेनरेटेड इंटरप्ट रजिस्टर (SGIR) और डीएक्टिवेट इंटरप्ट रजिस्टर (DIR) रजिस्टर ट्रैपिंग का समर्थन करने के लिए सरल बनाया जा सकता है। आर्किटेक्चर अनिवार्य करता है कि ये रजिस्टर हमेशा EL2 में ट्रैप करें, जबकि अन्य ट्रैप अब तक केवल इरेटा को कम करने के लिए उपयोगी रहे हैं। बाकी सब कुछ हार्डवेयर में संभाला जा रहा है।

एमएमआईओ की तरफ, केवीएम में सभी मौजूदा बुनियादी ढांचे का पुन: उपयोग करते हुए, ईएल1 में सब कुछ अनुकरण किया जाता है। अंत में, वेट फॉर इंटरप्ट (WFI) हमेशा EL1 को रिले किया जाता है, क्योंकि यह KVM द्वारा उपयोग किए जाने वाले बुनियादी शेड्यूलिंग आदिमों में से एक है।

टाइमर समर्थन

वर्चुअल टाइमर के लिए तुलनित्र मान प्रत्येक फंसने वाले WFI पर EL1 के संपर्क में होना चाहिए ताकि EL1 वीसीपीयू के अवरुद्ध होने पर टाइमर को बाधित कर सके। भौतिक टाइमर पूरी तरह से नकली है, और सभी ट्रैप EL1 पर रिले किए गए हैं।

एमएमआईओ हैंडलिंग

वर्चुअल मशीन मॉनिटर (VMM) के साथ संवाद करने और GIC एमुलेशन करने के लिए, MMIO ट्रैप को आगे की ट्राइएजिंग के लिए EL1 में होस्ट को वापस रिले किया जाना चाहिए। pKVM को निम्नलिखित की आवश्यकता है:

  • आईपीए और पहुंच का आकार
  • लिखने के मामले में डेटा
  • ट्रैपिंग के बिंदु पर सीपीयू की एंडियननेस

इसके अतिरिक्त, एक स्रोत/गंतव्य के रूप में एक सामान्य उद्देश्य रजिस्टर (जीपीआर) के साथ जाल एक सार हस्तांतरण छद्म-रजिस्टर का उपयोग करके रिले किया जाता है।

अतिथि इंटरफेस

एक अतिथि एक संरक्षित अतिथि के साथ हाइपरकॉल्स के संयोजन और फंसे हुए क्षेत्रों में मेमोरी एक्सेस का उपयोग कर संवाद कर सकता है। Hypercalls KVM द्वारा विक्रेता आवंटन के लिए आरक्षित श्रेणी के साथ, SMCCC मानक के अनुसार प्रकट होते हैं। निम्नलिखित हाइपरकॉल pKVM अतिथि के लिए विशेष महत्व रखते हैं।

सामान्य हाइपरकॉल

  • PSCI अतिथि को अपने vCPUs के जीवनचक्र को नियंत्रित करने के लिए एक मानक तंत्र प्रदान करता है जिसमें ऑनलाइनिंग, ऑफलाइनिंग और सिस्टम शटडाउन शामिल हैं।
  • TRNG अतिथि के लिए pKVM से एन्ट्रापी का अनुरोध करने के लिए एक मानक तंत्र प्रदान करता है जो कॉल को EL3 पर रिले करता है। यह तंत्र विशेष रूप से उपयोगी होता है जहां हार्डवेयर यादृच्छिक संख्या जेनरेटर (आरएनजी) वर्चुअलाइज करने के लिए होस्ट पर भरोसा नहीं किया जा सकता है।

pKVM हाइपरकॉल्स

  • मेजबान के साथ स्मृति साझा करना। सभी अतिथि स्मृति शुरू में मेजबान के लिए दुर्गम है, लेकिन साझा-स्मृति संचार के लिए और साझा बफ़र्स पर भरोसा करने वाले पैरावर्चुअलाइज्ड उपकरणों के लिए मेजबान पहुंच आवश्यक है। मेजबान के साथ पृष्ठों को साझा करने और साझा करने के लिए हाइपरकॉल अतिथि को यह तय करने की अनुमति देता है कि बिना हैंडशेक की आवश्यकता के मेमोरी के कौन से हिस्से बाकी एंड्रॉइड के लिए सुलभ हैं।
  • होस्ट को मेमोरी एक्सेस ट्रैपिंग। परंपरागत रूप से, यदि कोई KVM अतिथि किसी ऐसे पते तक पहुँचता है जो एक वैध स्मृति क्षेत्र से मेल नहीं खाता है, तो vCPU थ्रेड होस्ट से बाहर निकल जाता है और पहुँच आमतौर पर MMIO के लिए उपयोग की जाती है और VMM द्वारा उपयोगकर्ता स्थान में नकल की जाती है। इस हैंडलिंग को सुविधाजनक बनाने के लिए, pKVM को दोषपूर्ण निर्देश के बारे में विवरण जैसे कि इसका पता, रजिस्टर पैरामीटर और संभावित रूप से उनकी सामग्री वापस होस्ट को विज्ञापित करने की आवश्यकता है, जो अनजाने में संरक्षित अतिथि से संवेदनशील डेटा को उजागर कर सकता है यदि ट्रैप का अनुमान नहीं लगाया गया था। pKVM इन दोषों को घातक मानते हुए इस समस्या को हल करता है, जब तक कि अतिथि ने पहले से दोषपूर्ण IPA रेंज की पहचान करने के लिए एक हाइपरकॉल जारी नहीं किया है, जिसके लिए होस्ट को वापस ट्रैप करने की अनुमति है। इस समाधान को MMIO गार्ड कहा जाता है।

वर्चुअल I/O डिवाइस (virtio)

पैरावर्चुअलाइज्ड डिवाइसेस के साथ इंटरैक्ट करने और लागू करने के लिए वर्टिओ एक लोकप्रिय, पोर्टेबल और परिपक्व मानक है। संरक्षित अतिथियों के संपर्क में आने वाले अधिकांश उपकरण virtio का उपयोग करके कार्यान्वित किए जाते हैं। Virtio संरक्षित अतिथि और शेष Android के बीच संचार के लिए उपयोग किए जाने वाले vsock कार्यान्वयन को भी रेखांकित करता है।

Virtio डिवाइस को आमतौर पर VMM द्वारा होस्ट के यूजर स्पेस में कार्यान्वित किया जाता है, जो वर्चुअल डिवाइस के MMIO इंटरफ़ेस में अतिथि से फंसी हुई मेमोरी एक्सेस को इंटरसेप्ट करता है और अपेक्षित व्यवहार का अनुकरण करता है। MMIO एक्सेस अपेक्षाकृत महंगा है क्योंकि डिवाइस के लिए प्रत्येक एक्सेस के लिए VMM और वापस जाने के लिए एक राउंड-ट्रिप की आवश्यकता होती है, इसलिए डिवाइस और गेस्ट के बीच अधिकांश वास्तविक डेटा ट्रांसफर मेमोरी में वर्चुक्यूज़ के सेट का उपयोग करके होता है। सदाचार की एक प्रमुख धारणा यह है कि मेजबान अतिथि स्मृति को मनमाने ढंग से एक्सेस कर सकता है। यह धारणा पुण्य कतार के डिजाइन में स्पष्ट है, जिसमें अतिथि में बफ़र्स के लिए संकेत हो सकते हैं कि डिवाइस एमुलेशन को सीधे एक्सेस करने का इरादा है।

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

वर्चुअल डिवाइस

चित्रा 4. वर्टिओ डिवाइस

ट्रस्टज़ोन के साथ सहभागिता

हालांकि अतिथि ट्रस्टज़ोन के साथ सीधे बातचीत करने में सक्षम नहीं हैं, फिर भी मेजबान को सुरक्षित दुनिया में एसएमसी कॉल जारी करने में सक्षम होना चाहिए। ये कॉल भौतिक रूप से संबोधित मेमोरी बफ़र्स निर्दिष्ट कर सकते हैं जो होस्ट के लिए दुर्गम हैं। क्योंकि सुरक्षित सॉफ़्टवेयर आमतौर पर बफ़र की पहुंच से अनजान होता है, एक दुर्भावनापूर्ण होस्ट इस बफ़र का उपयोग भ्रमित डिप्टी अटैक (DMA अटैक के अनुरूप) करने के लिए कर सकता है। इस तरह के हमलों को रोकने के लिए, pKVM सभी होस्ट SMC कॉल को EL2 पर ट्रैप करता है और होस्ट और EL3 पर सुरक्षित मॉनिटर के बीच प्रॉक्सी के रूप में कार्य करता है।

होस्ट से PSCI कॉल न्यूनतम संशोधनों के साथ EL3 फर्मवेयर को अग्रेषित की जाती हैं। विशेष रूप से, सीपीयू के ऑनलाइन आने या सस्पेंड से फिर से शुरू होने के लिए प्रवेश बिंदु को फिर से लिखा जाता है ताकि ईएल1 पर होस्ट पर लौटने से पहले चरण 2 पृष्ठ तालिका ईएल2 पर स्थापित हो। बूट के दौरान, यह सुरक्षा pKVM द्वारा लागू की जाती है।

यह आर्किटेक्चर PSCI को सपोर्ट करने वाले SoC पर निर्भर करता है, अधिमानतः इसके EL3 फर्मवेयर के रूप में TF-A के अप-टू-डेट संस्करण के उपयोग के माध्यम से।

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

यह आर्किटेक्चर मेमोरी एक्सेस मॉडल को लागू करने वाले सुरक्षित विश्व सॉफ़्टवेयर पर निर्भर करता है, यह सुनिश्चित करने के लिए कि विश्वसनीय ऐप्स और सुरक्षित दुनिया में चल रहे कोई भी अन्य सॉफ़्टवेयर केवल तभी मेमोरी तक पहुंच सकते हैं जब यह या तो विशेष रूप से सुरक्षित दुनिया के स्वामित्व में हो या FF का उपयोग करके इसके साथ स्पष्ट रूप से साझा किया गया हो -एक। S-EL2 के साथ एक सिस्टम पर, मेमोरी एक्सेस मॉडल को लागू करना एक सुरक्षित विभाजन प्रबंधक कोर (SPMC) द्वारा किया जाना चाहिए, जैसे कि हैफ़नियम , जो सुरक्षित दुनिया के लिए चरण 2 पेज टेबल बनाए रखता है। S-EL2 के बिना सिस्टम पर, TEE इसके बजाय अपने चरण 1 पेज टेबल के माध्यम से मेमोरी एक्सेस मॉडल को लागू कर सकता है।

यदि EL2 के लिए SMC कॉल एक PSCI कॉल या FF-A परिभाषित संदेश नहीं है, तो हैंडल न किए गए SMCs EL3 को अग्रेषित किए जाते हैं। धारणा यह है कि (अनिवार्य रूप से विश्वसनीय) सुरक्षित फ़र्मवेयर हैंडल न किए गए SMCs को सुरक्षित रूप से संभाल सकता है क्योंकि फ़र्मवेयर pVM अलगाव को बनाए रखने के लिए आवश्यक सावधानियों को समझता है।

वर्चुअल मशीन मॉनिटर

crosvm एक वर्चुअल मशीन मॉनिटर (VMM) है जो Linux के KVM इंटरफ़ेस के माध्यम से वर्चुअल मशीन चलाता है। crosvm को जो विशिष्ट बनाता है वह है रस्ट प्रोग्रामिंग लैंग्वेज के उपयोग के साथ सुरक्षा पर ध्यान केंद्रित करना और होस्ट कर्नेल की सुरक्षा के लिए आभासी उपकरणों के चारों ओर एक सैंडबॉक्स।

फाइल डिस्क्रिप्टर और ioctls

KVM ioctls के साथ उपयोक्तास्थान के लिए /dev/kvm कैरेक्टर डिवाइस को प्रकट करता है जो KVM API बनाता है। Ioctls निम्नलिखित श्रेणियों से संबंधित हैं:

  • सिस्टम ioctls क्वेरी और वैश्विक विशेषताओं को सेट करता है जो पूरे KVM सबसिस्टम को प्रभावित करता है, और pVM बनाता है।
  • VM ioctls क्वेरी और सेट विशेषताएँ जो वर्चुअल CPUs (vCPUs) और डिवाइस बनाते हैं, और संपूर्ण pVM को प्रभावित करते हैं, जैसे कि मेमोरी लेआउट और वर्चुअल CPUs (vCPUs) और उपकरणों की संख्या शामिल है।
  • vCPU ioctls क्वेरी और सेट विशेषताएँ जो एकल वर्चुअल CPU के संचालन को नियंत्रित करती हैं।
  • डिवाइस ioctls क्वेरी और सेट विशेषताएँ जो एकल वर्चुअल डिवाइस के संचालन को नियंत्रित करती हैं।

प्रत्येक crosvm प्रक्रिया वर्चुअल मशीन का ठीक एक उदाहरण चलाती है। यह प्रक्रिया KVM_CREATE_VM सिस्टम ioctl का उपयोग VM फाइल डिस्क्रिप्टर बनाने के लिए करती है जिसका उपयोग pVM ioctls जारी करने के लिए किया जा सकता है। VM FD पर KVM_CREATE_VCPU या KVM_CREATE_DEVICE ioctl एक vCPU/डिवाइस बनाता है और नए संसाधन की ओर इशारा करते हुए एक फाइल डिस्क्रिप्टर लौटाता है। vCPU या डिवाइस FD पर ioctls का उपयोग उस डिवाइस को नियंत्रित करने के लिए किया जा सकता है जिसे VM FD पर ioctl का उपयोग करके बनाया गया था। वीसीपीयू के लिए, इसमें अतिथि कोड चलाने का महत्वपूर्ण कार्य शामिल है।

आंतरिक रूप से, crosvm एज-ट्रिगर epoll इंटरफ़ेस का उपयोग करके कर्नेल के साथ VM के फ़ाइल डिस्क्रिप्टर को पंजीकृत करता है। कर्नेल तब crosvm को सूचित करता है जब भी किसी फाइल डिस्क्रिप्टर में कोई नया ईवेंट लंबित होता है।

pKVM एक नई क्षमता, KVM_CAP_ARM_PROTECTED_VM जोड़ता है, जिसका उपयोग pVM वातावरण के बारे में जानकारी प्राप्त करने और VM के लिए सुरक्षित मोड सेट करने के लिए किया जा सकता है। crosvm pVM निर्माण के दौरान इसका उपयोग करता है यदि --protected-vm फ़्लैग पास किया जाता है, pVM फ़र्मवेयर के लिए उचित मात्रा में मेमोरी को क्वेरी और आरक्षित करने के लिए, और फिर सुरक्षित मोड को सक्षम करने के लिए।

स्मृति आवंटन

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

सामान्य मोड में एफडीटी PHYS_MEMORY_END - 0x200000
मुक्त स्थान ...
रैमडिस्क ALIGN_UP(KERNEL_END, 0x1000000)
गुठली 0x80080000
बूटलोडर 0x80200000
BIOS मोड में FDT 0x80000000
भौतिक स्मृति आधार 0x80000000
पीवीएम फर्मवेयर 0x7FE00000
उपकरण की स्मृति 0x10000 - 0x40000000

भौतिक मेमोरी को mmap के साथ आवंटित किया जाता है और मेमोरी को वीएम को इसके मेमोरी क्षेत्रों को पॉप्युलेट करने के लिए दान किया जाता है, जिसे मेम्सलॉट कहा जाता है, KVM_SET_USER_MEMORY_REGION ioctl के साथ। इसलिए सभी अतिथि pVM मेमोरी को crosvm उदाहरण के लिए जिम्मेदार ठहराया जाता है जो इसे प्रबंधित करता है और इसके परिणामस्वरूप प्रक्रिया समाप्त हो सकती है (VM को समाप्त करना) यदि होस्ट मुक्त मेमोरी से बाहर निकलना शुरू कर देता है। जब एक वीएम बंद हो जाता है, तो मेमोरी स्वचालित रूप से हाइपरवाइजर द्वारा मिटा दी जाती है और होस्ट कर्नेल में वापस आ जाती है।

नियमित केवीएम के तहत, वीएमएम सभी अतिथि मेमोरी तक पहुंच बनाए रखता है। pKVM के साथ, अतिथि स्मृति को अतिथि को दान किए जाने पर होस्ट भौतिक पता स्थान से मैप नहीं किया जाता है। एकमात्र अपवाद मेमोरी है जो स्पष्ट रूप से अतिथि द्वारा वापस साझा की जाती है, जैसे कि virtio उपकरणों के लिए।

अतिथि के पता स्थान में MMIO क्षेत्रों को मैप नहीं किया गया है। अतिथि द्वारा इन क्षेत्रों तक पहुंच फंस जाती है और वीएम एफडी पर एक आई/ओ घटना होती है। इस तंत्र का उपयोग आभासी उपकरणों को लागू करने के लिए किया जाता है। संरक्षित मोड में, अतिथि को यह स्वीकार करना चाहिए कि गलती से जानकारी लीक होने के जोखिम को कम करने के लिए हाइपरकॉल का उपयोग करके MMIO के लिए उसके पता स्थान के एक क्षेत्र का उपयोग किया जाता है।

निर्धारण

प्रत्येक वर्चुअल CPU को POSIX थ्रेड द्वारा दर्शाया जाता है और होस्ट Linux शेड्यूलर द्वारा शेड्यूल किया जाता है। थ्रेड KVM_RUN ioctl को vCPU FD पर कॉल करता है, जिसके परिणामस्वरूप हाइपरविजर अतिथि vCPU संदर्भ में स्विच हो जाता है। होस्ट शेड्यूलर अतिथि संदर्भ में बिताए गए समय को संबंधित vCPU थ्रेड द्वारा उपयोग किए गए समय के रूप में बताता है। KVM_RUN तब वापस आता है जब कोई घटना होती है जिसे VMM द्वारा नियंत्रित किया जाना चाहिए, जैसे कि I/O, रुकावट का अंत, या vCPU रुका हुआ। VMM ईवेंट को हैंडल करता है और KVM_RUN फिर से कॉल करता है।

KVM_RUN के दौरान, EL2 हाइपरविजर कोड के निष्पादन को छोड़कर, थ्रेड होस्ट शेड्यूलर द्वारा प्रीमेप्टेबल रहता है, जो प्रीमेप्टिबल नहीं है। अतिथि pVM के पास स्वयं इस व्यवहार को नियंत्रित करने के लिए कोई तंत्र नहीं है।

क्योंकि सभी vCPU थ्रेड्स किसी अन्य यूज़रस्पेस कार्यों की तरह शेड्यूल किए गए हैं, वे सभी मानक QoS तंत्रों के अधीन हैं। विशेष रूप से, प्रत्येक vCPU थ्रेड को भौतिक CPU से संबद्ध किया जा सकता है, cpusets में रखा जा सकता है, उपयोग क्लैम्पिंग का उपयोग करके बढ़ाया या कैप किया जा सकता है, उनकी प्राथमिकता/शेड्यूलिंग नीति बदली जा सकती है, और बहुत कुछ।

आभासी उपकरण

crosvm निम्नलिखित सहित कई उपकरणों का समर्थन करता है:

  • समग्र डिस्क छवियों के लिए virtio-blk, केवल-पढ़ने या पढ़ने-लिखने के लिए
  • मेजबान के साथ संचार के लिए vhost-vsock
  • virtio-pci virtio ट्रांसपोर्ट के रूप में
  • pl030 वास्तविक समय घड़ी (आरटीसी)
  • धारावाहिक संचार के लिए 16550a UART

पीवीएम फर्मवेयर

पीवीएम फर्मवेयर (pvmfw) एक भौतिक डिवाइस के बूट रोम के समान एक पीवीएम द्वारा निष्पादित पहला कोड है। pvmfw का प्राथमिक लक्ष्य सुरक्षित बूट को बूटस्ट्रैप करना और pVM के अनूठे रहस्य को प्राप्त करना है। pvmfw किसी विशिष्ट OS के साथ उपयोग करने के लिए सीमित नहीं है, जैसे कि Microdroid , जब तक कि OS crosvm द्वारा समर्थित है और उचित रूप से हस्ताक्षरित है।

pvmfw बायनरी को उसी नाम के एक फ्लैश पार्टीशन में स्टोर किया जाता है और OTA का उपयोग करके अपडेट किया जाता है।

डिवाइस बूट

pKVM-सक्षम युक्ति की बूट प्रक्रिया में चरणों का निम्नलिखित क्रम जोड़ा जाता है:

  1. Android बूटलोडर (ABL) pvmfw को उसके विभाजन से स्मृति में लोड करता है और छवि की पुष्टि करता है।
  2. ABL अपने डिवाइस आइडेंटिफ़ायर कंपोजिशन इंजन (DICE) सीक्रेट्स (कंपाउंड डिवाइस आइडेंटिफ़ायर (CDIs) और बूट सर्टिफिकेट चेन (BCC)) को रूट ऑफ़ ट्रस्ट से प्राप्त करता है।
  3. ABL pvmfw के रहस्यों (CDI) का मापन और DICE व्युत्पत्ति करता है, और उन्हें pvmfw बाइनरी में जोड़ता है।
  4. ABL एक linux,pkvm-guest-firmware-memory आरक्षित मेमोरी क्षेत्र नोड को DT में जोड़ता है, pvmfw बाइनरी के स्थान और आकार का वर्णन करता है और पिछले चरण में इसे प्राप्त करता है।
  5. ABL नियंत्रण Linux को सौंपता है और Linux pKVM को इनिशियलाइज़ करता है।
  6. pKVM pvmfw मेमोरी रीजन को होस्ट के स्टेज 2 पेज टेबल से अनमैप करता है और इसे पूरे डिवाइस अपटाइम में होस्ट (और मेहमानों) से बचाता है।

डिवाइस बूट के बाद, माइक्रोड्रॉइड दस्तावेज़ के बूट अनुक्रम अनुभाग में चरणों के अनुसार माइक्रोड्रॉइड को बूट किया जाता है।

पीवीएम बूट

एक pVM बनाते समय, crosvm (या अन्य VMM) को हाइपरविजर द्वारा pvmfw छवि के साथ पॉप्युलेट होने के लिए पर्याप्त रूप से बड़ा मेमस्लॉट बनाना चाहिए। वीएमएम उन रजिस्टरों की सूची में भी प्रतिबंधित है जिनका प्रारंभिक मूल्य यह निर्धारित कर सकता है (प्राथमिक वीसीपीयू के लिए x0-x14, द्वितीयक वीसीपीयू के लिए कोई नहीं)। शेष रजिस्टर आरक्षित हैं और हाइपरवाइजर-pvmfw ABI का हिस्सा हैं।

जब pVM चलाया जाता है, तो हाइपरविजर पहले प्राथमिक vCPU का नियंत्रण pvmfw को सौंपता है। फर्मवेयर को उम्मीद है कि crosvm ने एक AVB-हस्ताक्षरित कर्नेल लोड किया है, जो एक बूटलोडर या कोई अन्य छवि हो सकती है, और ज्ञात ऑफ़सेट पर स्मृति के लिए एक अहस्ताक्षरित FDT हो सकता है। pvmfw AVB हस्ताक्षर को मान्य करता है और सफल होने पर, प्राप्त FDT से एक विश्वसनीय डिवाइस ट्री उत्पन्न करता है, इसके रहस्यों को स्मृति से मिटा देता है, और शाखाओं को पेलोड के प्रवेश बिंदु तक पहुँचा देता है। यदि कोई सत्यापन चरण विफल हो जाता है, तो फ़र्मवेयर एक PSCI SYSTEM_RESET हाइपरकॉल जारी करता है।

बूट के बीच, pVM उदाहरण के बारे में जानकारी एक विभाजन (virtio-blk डिवाइस) में संग्रहीत की जाती है और यह सुनिश्चित करने के लिए pvmfw के रहस्य के साथ एन्क्रिप्ट किया जाता है कि, रिबूट के बाद, रहस्य को सही उदाहरण के लिए प्रावधान किया जा रहा है।