एवीएफ़ आर्किटेक्चर

Android, Android वर्चुअलाइज़ेशन फ़्रेमवर्क को लागू करने के लिए ज़रूरी सभी कॉम्पोनेंट का रेफ़रंस लागू करता है. फ़िलहाल, यह सुविधा सिर्फ़ ARM64 के लिए उपलब्ध है. इस पेज पर, फ़्रेमवर्क के आर्किटेक्चर के बारे में बताया गया है.

बैकग्राउंड

Arm आर्किटेक्चर में चार एक्सेप्शन लेवल होते हैं. इनमें एक्सेप्शन लेवल 0 (EL0) को सबसे कम और एक्सेप्शन लेवल 3 (EL3) को सबसे ज़्यादा प्राथमिकता दी जाती है. Android के कोडबेस का सबसे बड़ा हिस्सा (सभी यूज़रस्पेस कॉम्पोनेंट) EL0 पर चलता है. "Android" के बाकी हिस्से में Linux कर्नेल होता है, जो EL1 पर चलता है.

EL2 लेयर की मदद से, हाइपरवाइज़र को पेश किया जा सकता है. इससे EL1/EL0 पर मौजूद मेमोरी और डिवाइसों को अलग-अलग pVM में बांटा जा सकता है. साथ ही, यह भी पक्का किया जा सकता है कि इनकी गोपनीयता और अखंडता बनी रहे.

हाइपरवाइज़र

सुरक्षित कर्नल पर आधारित वर्चुअल मशीन (पीकेवीएम) को Linux KVM हाइपरवाइज़र पर बनाया गया है. इसे इस तरह से बनाया गया है कि यह गेस्ट वर्चुअल मशीनों में चल रहे पेलोड के ऐक्सेस को सीमित कर सकता है. इन मशीनों को बनाते समय ‘सुरक्षित’ के तौर पर मार्क किया गया था.

KVM/arm64, सीपीयू की कुछ सुविधाओं की उपलब्धता के आधार पर अलग-अलग एक्ज़ीक्यूशन मोड के साथ काम करता है. जैसे, वर्चुअलाइज़ेशन होस्ट एक्सटेंशन (वीएचई) (ARMv8.1 और उसके बाद के वर्शन). इनमें से एक मोड को आम तौर पर नॉन-वीएचई मोड के तौर पर जाना जाता है. इस मोड में, बूट के दौरान हाइपरवाइज़र कोड को कर्नल इमेज से अलग कर दिया जाता है और EL2 पर इंस्टॉल कर दिया जाता है. वहीं, कर्नल खुद EL1 पर चलता है. KVM का EL2 कॉम्पोनेंट, Linux कोडबेस का हिस्सा है. हालांकि, यह एक छोटा कॉम्पोनेंट है. इसका काम, कई EL1 के बीच स्विच करना है. हाइपरवाइज़र कॉम्पोनेंट को Linux के साथ कंपाइल किया जाता है. हालांकि, यह vmlinux इमेज के अलग और खास मेमोरी सेक्शन में मौजूद होता है. pKVM इस डिज़ाइन का इस्तेमाल करता है. इसके लिए, वह हाइपरवाइज़र कोड को नई सुविधाओं के साथ बढ़ाता है. इससे, Android होस्ट कर्नल और उपयोगकर्ता स्पेस पर पाबंदियां लगाई जा सकती हैं. साथ ही, होस्ट के ऐक्सेस को गेस्ट मेमोरी और हाइपरवाइज़र तक सीमित किया जा सकता है.

pKVM वेंडर मॉड्यूल

pKVM वेंडर मॉड्यूल, हार्डवेयर के हिसाब से बनाया गया मॉड्यूल होता है. इसमें डिवाइस के हिसाब से काम करने वाली सुविधाएं होती हैं. जैसे, इनपुट-आउटपुट मेमोरी मैनेजमेंट यूनिट (आईओएमएमयू) ड्राइवर. इन मॉड्यूल की मदद से, सुरक्षा से जुड़ी उन सुविधाओं को pKVM पर पोर्ट किया जा सकता है जिनके लिए, एक्सेप्शन लेवल 2 (EL2) ऐक्सेस की ज़रूरत होती है.

pKVM वेंडर मॉड्यूल को लागू करने और लोड करने का तरीका जानने के लिए, pKVM वेंडर मॉड्यूल लागू करना लेख पढ़ें.

बूट करने की प्रोसेस

इस इमेज में, pKVM बूट करने की प्रोसेस दिखाई गई है:

1. शुरुआत: बूटलोडर, EL2 पर सामान्य कर्नल में प्रवेश करता है. इसके बाद, EL2 और EL1, दोनों पर भरोसेमंद कर्नल कोड, pKVM और उसके मॉड्यूल को शुरू करता है. इस फ़ेज़ के दौरान, EL2 को EL1 पर भरोसा होता है. इसलिए, किसी ऐसे कोड को नहीं चलाया जाता जिस पर भरोसा नहीं किया जा सकता.
2. कर्नेल को कम विशेषाधिकार देना: सामान्य कर्नेल का पता लगाता है कि यह EL2 पर चल रहा है और खुद को EL1 पर कम विशेषाधिकार देता है. pKVM और इसके मॉड्यूल, EL2 पर चलते रहते हैं.
3. रनटाइम: सामान्य कर्नल, सामान्य तरीके से बूट होता है. यह उपयोगकर्ता स्पेस तक पहुंचने तक, सभी ज़रूरी डिवाइस ड्राइवर लोड करता है. इस समय, pKVM चालू होता है और स्टेज-2 की पेज टेबल को मैनेज करता है.

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

Android कर्नल और हाइपरवाइज़र को एक ही बाइनरी इमेज में रखने से, उनके बीच बहुत कम समय में डेटा ट्रांसफ़र हो पाता है. इन दोनों कॉम्पोनेंट को एक साथ अपडेट किया जाता है. इससे, इनके बीच इंटरफ़ेस को स्थिर रखने की ज़रूरत नहीं पड़ती. साथ ही, लंबे समय तक रखरखाव में कोई समस्या नहीं आती. इन दोनों कॉम्पोनेंट के बीच बेहतर तरीके से इंटिग्रेशन होने की वजह से, परफ़ॉर्मेंस को ऑप्टिमाइज़ किया जा सकता है. ऐसा तब होता है, जब दोनों कॉम्पोनेंट हाइपरवाइज़र की सुरक्षा से जुड़ी गारंटी पर असर डाले बिना एक-दूसरे के साथ काम कर सकते हैं.

इसके अलावा, Android इकोसिस्टम में जीकेआई को अपनाने से, pKVM हाइपरवाइज़र को Android डिवाइसों पर अपने-आप डिप्लॉय किया जा सकता है. यह कर्नेल के साथ एक ही बाइनरी में होता है.

सीपीयू की मेमोरी ऐक्सेस करने से जुड़ी सुरक्षा

आर्म आर्किटेक्चर में, मेमोरी मैनेजमेंट यूनिट (एमएमयू) को दो अलग-अलग चरणों में बांटा गया है. इन दोनों चरणों का इस्तेमाल, पते के अनुवाद और मेमोरी के अलग-अलग हिस्सों को ऐक्सेस कंट्रोल करने के लिए किया जा सकता है. पहले चरण के एमएमयू को EL1 कंट्रोल करता है. इससे पते का अनुवाद पहले लेवल पर किया जा सकता है. पहले चरण के एमएमयू का इस्तेमाल Linux करता है. इससे हर यूज़रस्पेस प्रोसेस और उसके वर्चुअल पता स्पेस को दिए गए वर्चुअल पता स्पेस को मैनेज किया जाता है.

स्टेज 2 एमएमयू को EL2 कंट्रोल करता है. यह स्टेज 1 एमएमयू के आउटपुट पते पर दूसरे पते के अनुवाद को लागू करता है. इससे फ़िज़िकल पता (पीए) मिलता है. दूसरे चरण में अनुवाद करने की सुविधा का इस्तेमाल हाइपरवाइज़र कर सकते हैं. इससे वे सभी गेस्ट वीएम से मेमोरी ऐक्सेस को कंट्रोल और उनका अनुवाद कर सकते हैं. दूसरी इमेज में दिखाया गया है कि अनुवाद के दोनों चरणों के चालू होने पर, पहले चरण के आउटपुट पते को इंटरमीडिएट फ़िज़िकल पता (आईपीए) कहा जाता है. ध्यान दें: वर्चुअल पते (वीए) का अनुवाद पहले आईपीए में किया जाता है. इसके बाद, इसे पीए में बदला जाता है.

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

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

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

जैसा कि पहले बताया गया है, सीपीयू पेज टेबल में Linux होस्ट से गेस्ट पेज को अनमैप करना, गेस्ट मेमोरी को सुरक्षित रखने के लिए ज़रूरी है. हालांकि, यह काफ़ी नहीं है. pKVM को होस्ट कर्नल के कंट्रोल में मौजूद, डीएमए की सुविधा वाले डिवाइसों के मेमोरी ऐक्सेस से भी सुरक्षा करनी होती है. साथ ही, उसे किसी दुर्भावनापूर्ण होस्ट की ओर से शुरू किए गए डीएमए हमले से भी सुरक्षा करनी होती है. ऐसे डिवाइस को गेस्ट मेमोरी ऐक्सेस करने से रोकने के लिए, pKVM को सिस्टम में DMA की सुविधा वाले हर डिवाइस के लिए, इनपुट-आउटपुट मेमोरी मैनेजमेंट यूनिट (IOMMU) हार्डवेयर की ज़रूरत होती है. इसे इमेज 3 में दिखाया गया है.

कम से कम, IOMMU हार्डवेयर, डिवाइस को पेज के हिसाब से फ़िज़िकल मेमोरी के लिए पढ़ने/लिखने का ऐक्सेस देने और रद्द करने का तरीका उपलब्ध कराता है. हालांकि, यह IOMMU हार्डवेयर, pVM में डिवाइसों के इस्तेमाल को सीमित करता है, क्योंकि वे आइडेंटिटी-मैप किए गए दूसरे चरण को मानते हैं.

वर्चुअल मशीनों को अलग-अलग रखने के लिए, अलग-अलग इकाइयों की ओर से जनरेट किए गए मेमोरी लेन-देन को आईओएमएमयू से अलग किया जाना चाहिए, ताकि अनुवाद के लिए पेज टेबल के सही सेट का इस्तेमाल किया जा सके.

इसके अलावा, EL2 पर एसओसी के हिसाब से कोड की मात्रा को कम करना, pKVM के कुल भरोसेमंद कंप्यूटिंग बेस (टीसीबी) को कम करने की एक अहम रणनीति है. साथ ही, यह हाइपरवाइज़र में आईओएमएमयू ड्राइवर को शामिल करने के ख़िलाफ़ है. इस समस्या को कम करने के लिए, EL1 पर मौजूद होस्ट, IOMMU को मैनेज करने से जुड़े सहायक टास्क के लिए ज़िम्मेदार होता है. जैसे, पावर मैनेजमेंट, शुरू करना, और जहां ज़रूरी हो वहां इंटरप्ट हैंडल करना.

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

आइसोलेशन और डायरेक्ट असाइनमेंट, दोनों को मुमकिन बनाने के लिए, आर्म डिवाइसों के लिए स्टैंडर्ड और अच्छी तरह से काम करने वाली आईओएमएमयू, आर्म सिस्टम मेमोरी मैनेजमेंट यूनिट (एसएमएमयू) आर्किटेक्चर है. हमारा सुझाव है कि आप इस आर्किटेक्चर का इस्तेमाल करें.

मेमोरी का मालिकाना हक

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

होस्ट और मेहमानों के बीच बातचीत, मेमोरी को कंट्रोल करके शेयर करने की सुविधा की वजह से हो पाती है. मेहमानों को हाइपरकॉल का इस्तेमाल करके, अपने कुछ पेजों को होस्ट के साथ वापस शेयर करने की अनुमति होती है. इससे हाइपरवाइज़र को होस्ट के स्टेज 2 पेज टेबल में उन पेजों को फिर से मैप करने का निर्देश मिलता है. इसी तरह, होस्ट और TrustZone के बीच कम्यूनिकेशन, मेमोरी शेयर करने और/या मेमोरी उधार लेने की कार्रवाइयों की वजह से हो पाता है. इन सभी कार्रवाइयों पर pKVM की नज़र रहती है और वह इन्हें कंट्रोल करता है. इसके लिए, वह आर्म के लिए फ़र्मवेयर फ़्रेमवर्क (FF-A) स्पेसिफ़िकेशन का इस्तेमाल करता है.

समय के साथ-साथ, pVM की मेमोरी की ज़रूरतें बदल सकती हैं. इसलिए, एक हाइपरकॉल उपलब्ध कराया जाता है. इससे, कॉल करने वाले व्यक्ति के पास मौजूद पेजों का मालिकाना हक वापस होस्ट को दिया जा सकता है. इस हाइपरकॉल का इस्तेमाल, virtio balloon प्रोटोकॉल के साथ किया जाता है. इससे वीएमएम, पीवीएम से मेमोरी वापस पाने का अनुरोध कर सकता है. साथ ही, पीवीएम, वीएमएम को छोड़े गए पेजों के बारे में सूचना दे सकता है. यह सब कंट्रोल किए गए तरीके से होता है.

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

होस्ट को यह पक्का करना होगा कि वह उन पेजों को ऐक्सेस करने की कोशिश न करे जिन्हें हाइपरवाइज़र ने ऐक्सेस करने से रोक दिया है. होस्ट को गैर-कानूनी तरीके से ऐक्सेस करने पर, हाइपरवाइज़र होस्ट में एक सिंक्रोनस अपवाद डालता है. इससे, यूज़रस्पेस टास्क को SEGV सिग्नल मिल सकता है या होस्ट कर्नल क्रैश हो सकता है. अनजाने में होने वाले ऐक्सेस को रोकने के लिए, मेहमानों को दान किए गए पेजों को होस्ट कर्नल स्वैप या मर्ज नहीं कर सकता.

रुकावटों को मैनेज करना और टाइमर

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

pKVM, मौजूदा KVM कोड के आधार पर, पूरी तरह से जेनेरिक इंटरप्ट कंट्रोलर वर्शन 3 (GICv3) इम्यूलेशन उपलब्ध कराता है. टाइमर और आईपीआई को, भरोसेमंद न माने जाने वाले इस इम्यूलेशन कोड के हिस्से के तौर पर हैंडल किया जाता है.

GICv3 के साथ काम करता है

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

सिस्टम रजिस्टर रनटाइम सपोर्ट कोड को आसान बनाया जा सकता है, ताकि यह सिर्फ़ सॉफ़्टवेयर जनरेटेड इंटरप्ट रजिस्टर (एसजीआईआर) और डीऐक्टिवेट इंटरप्ट रजिस्टर (डीआईआर) रजिस्टर ट्रैपिंग के साथ काम कर सके. आर्किटेक्चर के मुताबिक, इन रजिस्टर को हमेशा EL2 पर ट्रैप करना होता है. वहीं, अन्य ट्रैप अब तक सिर्फ़ errata को कम करने के लिए फ़ायदेमंद रहे हैं. बाकी सभी काम हार्डवेयर में किए जा रहे हैं.

MMIO की तरफ़ से, EL1 पर हर चीज़ का इम्यूलेशन किया जाता है. साथ ही, KVM में मौजूद सभी मौजूदा इन्फ़्रास्ट्रक्चर का फिर से इस्तेमाल किया जाता है. आखिर में, Wait for Interrupt (WFI) को हमेशा EL1 पर भेजा जाता है, क्योंकि यह KVM की बुनियादी शेड्यूलिंग प्रिमिटिव में से एक है.

टाइमर की सुविधा

वर्चुअल टाइमर के लिए तुलना करने वाली वैल्यू को हर ट्रैपिंग WFI पर EL1 को दिखाना होगा, ताकि EL1, vCPU के ब्लॉक होने पर टाइमर इंटरप्ट इंजेक्ट कर सके. फ़िज़िकल टाइमर पूरी तरह से इम्यूलेट किया जाता है और सभी ट्रैप EL1 को भेजे जाते हैं.

MMIO हैंडलिंग

वर्चुअल मशीन मॉनिटर (वीएमएम) से कम्यूनिकेट करने और जीआईसी इम्यूलेशन करने के लिए, एमएमआईओ ट्रैप को EL1 में होस्ट को वापस भेजना होगा, ताकि आगे की जांच की जा सके. pKVM के लिए, ये ज़रूरी शर्तें पूरी होनी चाहिए:

• आईपीए और ऐक्सेस का साइज़
• लिखने के अनुरोध के मामले में डेटा
• ट्रैपिंग के समय सीपीयू का एंडियननेस

इसके अलावा, सामान्य मकसद के रजिस्टर (जीपीआर) को सोर्स/डेस्टिनेशन के तौर पर इस्तेमाल करने वाले ट्रैप को, ऐब्स्ट्रैक्ट ट्रांसफ़र स्यूडो-रजिस्टर का इस्तेमाल करके रिले किया जाता है.

मेहमान मोड में इस्तेमाल किए जाने वाले इंटरफ़ेस

कोई मेहमान, सुरक्षित मेहमान से बातचीत कर सकता है. इसके लिए, वह हाइपरकॉल और ट्रैप्ड क्षेत्रों में मेमोरी ऐक्सेस करने की सुविधा का इस्तेमाल करता है. हाइपरकॉल, एसएमसीसीसी स्टैंडर्ड के हिसाब से दिखाए जाते हैं. साथ ही, केवीएम के ज़रिए वेंडर के लिए एक रेंज रिज़र्व की जाती है. नीचे दिए गए हाइपरकॉल, pKVM गेस्ट के लिए खास तौर पर ज़रूरी हैं.

जेनेरिक हाइपरकॉल

• PSCI, मेहमान को अपने vCPU के लाइफ़साइकल को कंट्रोल करने के लिए एक स्टैंडर्ड तरीका उपलब्ध कराता है. इसमें ऑनलाइन करना, ऑफ़लाइन करना, और सिस्टम बंद करना शामिल है.
• टीआरएनजी, मेहमान को पीकेवीएम से एंट्रॉपी का अनुरोध करने के लिए एक स्टैंडर्ड तरीका उपलब्ध कराता है. पीकेवीएम, कॉल को EL3 पर रिले करता है. यह तरीका खास तौर पर तब काम आता है, जब होस्ट पर हार्डवेयर रैंडम नंबर जनरेटर (आरएनजी) को वर्चुअलाइज़ करने के लिए भरोसा नहीं किया जा सकता.

pKVM हाइपरकॉल

• होस्ट के साथ यादें शेयर करना. शुरुआत में, मेहमान के पास मौजूद मेमोरी को होस्ट ऐक्सेस नहीं कर सकता. हालांकि, शेयर की गई मेमोरी से कम्यूनिकेट करने और शेयर किए गए बफ़र पर निर्भर रहने वाले पैरावर्चुअलाइज़्ड डिवाइसों के लिए, होस्ट का ऐक्सेस ज़रूरी होता है. होस्ट के साथ पेजों को शेयर करने और अनशेयर करने के लिए हाइपरकॉल की सुविधा उपलब्ध है. इससे मेहमान को यह तय करने की अनुमति मिलती है कि मेमोरी के किन हिस्सों को Android के बाकी हिस्सों के लिए उपलब्ध कराया जाए. इसके लिए, हैंडशेक की ज़रूरत नहीं होती.
• होस्ट को मेमोरी वापस देना. आम तौर पर, मेहमान ओएस की मेमोरी तब तक मेहमान ओएस के पास रहती है, जब तक उसे डिस्ट्रॉय नहीं किया जाता. यह स्थिति, लंबे समय तक चलने वाली उन वर्चुअल मशीन (वीएम) के लिए सही नहीं हो सकती जिनकी मेमोरी की ज़रूरतें समय के साथ बदलती रहती हैं. relinquish हाइपरकॉल की मदद से, मेहमान के पास पेजों का मालिकाना हक वापस होस्ट को ट्रांसफ़र करने का विकल्प होता है. इसके लिए, मेहमान के तौर पर उसका ऐक्सेस खत्म करने की ज़रूरत नहीं होती.
• मेमोरी ऐक्सेस ट्रैपिंग को होस्ट करें. आम तौर पर, अगर KVM गेस्ट किसी ऐसे पते को ऐक्सेस करता है जो मान्य मेमोरी क्षेत्र से मेल नहीं खाता है, तो vCPU थ्रेड होस्ट से बाहर निकल जाता है. साथ ही, ऐक्सेस का इस्तेमाल आम तौर पर MMIO के लिए किया जाता है. इसे उपयोगकर्ता स्पेस में VMM से इम्यूलेट किया जाता है. इस प्रोसेस को आसान बनाने के लिए, pKVM को गड़बड़ी वाले निर्देश के बारे में जानकारी देनी होती है. जैसे, उसका पता, रजिस्टर पैरामीटर, और संभावित तौर पर उनकी सामग्री को वापस होस्ट पर भेजना होता है. इससे, सुरक्षित गेस्ट से संवेदनशील डेटा अनजाने में लीक हो सकता है. ऐसा तब होता है, जब ट्रैप का अनुमान न लगाया गया हो. pKVM इस समस्या को हल करता है. इसके लिए, वह इन गड़बड़ियों को गंभीर मानता है. हालांकि, ऐसा तब तक होता है, जब तक गेस्ट ने पहले से ही गड़बड़ी वाली आईपीए रेंज की पहचान करने के लिए हाइपरकॉल जारी न किया हो. इस रेंज के लिए, होस्ट को वापस ट्रैप करने की अनुमति दी जाती है. इस समाधान को MMIO गार्ड कहा जाता है.

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

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

आम तौर पर, Virtio डिवाइसों को होस्ट के उपयोगकर्ता स्पेस में VMM लागू करता है. यह Virtio डिवाइस के MMIO इंटरफ़ेस से मेहमान के ट्रैप्ड मेमोरी ऐक्सेस को इंटरसेप्ट करता है और अनुमानित व्यवहार का अनुकरण करता है. MMIO ऐक्सेस करना महंगा होता है, क्योंकि डिवाइस को हर बार ऐक्सेस करने के लिए, VMM को राउंड-ट्रिप करना पड़ता है. इसलिए, डिवाइस और गेस्ट के बीच ज़्यादातर डेटा ट्रांसफ़र, मेमोरी में मौजूद virtqueues के सेट का इस्तेमाल करके होता है. virtio की मुख्य मान्यता यह है कि होस्ट, मेहमान की मेमोरी को अपनी मर्ज़ी से ऐक्सेस कर सकता है. यह अनुमान, virtqueue के डिज़ाइन में दिखता है. इसमें मेहमान के बफ़र के पॉइंटर शामिल हो सकते हैं. डिवाइस इम्यूलेशन को सीधे तौर पर ऐक्सेस करने के लिए डिज़ाइन किया गया है.

हालांकि, पहले बताए गए मेमोरी शेयरिंग हाइपरकॉल का इस्तेमाल, मेहमान से होस्ट तक virtio डेटा बफ़र शेयर करने के लिए किया जा सकता है. हालांकि, यह शेयरिंग पेज के हिसाब से की जाती है. अगर बफ़र का साइज़ पेज के साइज़ से कम है, तो इससे ज़रूरत से ज़्यादा डेटा का पता चल सकता है. इसके बजाय, गेस्ट को शेयर की गई मेमोरी की तय की गई विंडो से, दोनों वर्टक्वी और उनके डेटा बफ़र को असाइन करने के लिए कॉन्फ़िगर किया जाता है. साथ ही, ज़रूरत के मुताबिक डेटा को विंडो में कॉपी (बाउंस) किया जाता है.

TrustZone के साथ इंटरैक्शन

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

होस्ट से मिले पीएससीआई कॉल, EL3 फ़र्मवेयर को फ़ॉरवर्ड किए जाते हैं. इनमें बहुत कम बदलाव किए जाते हैं. खास तौर पर, सीपीयू के ऑनलाइन होने या निलंबित होने के बाद फिर से शुरू होने के एंट्री पॉइंट को फिर से लिखा जाता है, ताकि स्टेज 2 की पेज टेबल को EL2 पर इंस्टॉल किया जा सके. इसके बाद, इसे EL1 पर होस्ट को वापस भेजा जा सके. बूट के दौरान, इस सुरक्षा को pKVM लागू करता है.

यह आर्किटेक्चर, SoC पर PSCI की सुविधा पर निर्भर करता है. इसके लिए, EL3 फ़र्मवेयर के तौर पर TF-A के अप-टू-डेट वर्शन का इस्तेमाल करना बेहतर होता है.

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

यह आर्किटेक्चर, Secure World सॉफ़्टवेयर पर निर्भर करता है. यह सॉफ़्टवेयर, मेमोरी ऐक्सेस मॉडल को लागू करता है. इससे यह पक्का किया जाता है कि Secure World में चल रहे भरोसेमंद ऐप्लिकेशन और अन्य सॉफ़्टवेयर, मेमोरी को सिर्फ़ तब ऐक्सेस कर सकते हैं, जब वह Secure World के पास हो या उसे FF-A का इस्तेमाल करके, Secure World के साथ शेयर किया गया हो. S-EL2 वाले सिस्टम पर, मेमोरी ऐक्सेस मॉडल को लागू करने का काम, Secure Partition Manager Core (SPMC) को करना चाहिए. जैसे, Hafnium. यह सुरक्षित दुनिया के लिए, दूसरे चरण की पेज टेबल को बनाए रखता है. S-EL2 के बिना किसी सिस्टम पर, टीईई अपनी पहली स्टेज की पेज टेबल के ज़रिए, मेमोरी ऐक्सेस मॉडल लागू कर सकता है.

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

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

crosvm एक वर्चुअल मशीन मॉनिटर (वीएमएम) है. यह Linux के KVM इंटरफ़ेस के ज़रिए वर्चुअल मशीनें चलाता है. crosvm को खास बनाने वाली बात यह है कि यह सुरक्षा पर फ़ोकस करता है. इसके लिए, Rust प्रोग्रामिंग लैंग्वेज का इस्तेमाल किया जाता है. साथ ही, होस्ट कर्नल की सुरक्षा के लिए वर्चुअल डिवाइसों के आस-पास एक सैंडबॉक्स बनाया जाता है. crosvm के बारे में ज़्यादा जानने के लिए, इसका आधिकारिक दस्तावेज़ यहां देखें.

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

KVM, /dev/kvm कैरेक्टर डिवाइस को userspace के लिए उपलब्ध कराता है. इसमें ioctl होते हैं, जो KVM API बनाते हैं. ioctls को इन कैटगरी में बांटा गया है:

• सिस्टम ioctls, पूरे KVM सबसिस्टम पर असर डालने वाले ग्लोबल एट्रिब्यूट को क्वेरी और सेट करते हैं. साथ ही, pVM बनाते हैं.
• VM ioctls, ऐसे एट्रिब्यूट के बारे में क्वेरी करते हैं और उन्हें सेट करते हैं जो वर्चुअल सीपीयू (वीसीपीयू) और डिवाइस बनाते हैं. साथ ही, ये पूरे pVM पर असर डालते हैं. जैसे, मेमोरी लेआउट और वर्चुअल सीपीयू (वीसीपीयू) और डिवाइसों की संख्या.
• vCPU ioctls, ऐसे एट्रिब्यूट को क्वेरी और सेट करते हैं जो किसी एक वर्चुअल सीपीयू के ऑपरेशन को कंट्रोल करते हैं.
• डिवाइस ioctls, एक वर्चुअल डिवाइस के ऑपरेशन को कंट्रोल करने वाले एट्रिब्यूट के बारे में क्वेरी करते हैं और उन्हें सेट करते हैं.

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

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

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

मेमोरी का बंटवारा

वीएमएम की मुख्य ज़िम्मेदारियों में से एक, वीएम की मेमोरी को असाइन करना और उसके मेमोरी लेआउट को मैनेज करना है. crosvm, एक तय मेमोरी लेआउट जनरेट करता है. इसके बारे में यहां दी गई टेबल में बताया गया है.

सामान्य मोड में एफ़डीटी	PHYS_MEMORY_END - 0x200000
स्टोरेज खाली करें	...
रैमडिस्क	ALIGN_UP(KERNEL_END, 0x1000000)
कर्नेल	0x80080000
बूटलोडर	0x80200000
BIOS मोड में FDT	0x80000000
फ़िज़िकल मेमोरी बेस	0x80000000
pVM फ़र्मवेयर	0x7FE00000
डिवाइस की मेमोरी	0x10000 - 0x40000000

फ़िजिकल मेमोरी को mmap के साथ असाइन किया जाता है. साथ ही, मेमोरी को वीएम को दिया जाता है, ताकि वह अपनी मेमोरी रीजन को भर सके. इन्हें memslots कहा जाता है. इसके लिए, KVM_SET_USER_MEMORY_REGION ioctl का इस्तेमाल किया जाता है. इसलिए, मेहमान pVM की पूरी मेमोरी को उस crosvm इंस्टेंस के लिए एट्रिब्यूट किया जाता है जो इसे मैनेज करता है. अगर होस्ट के पास खाली मेमोरी कम होने लगती है, तो इस प्रोसेस को बंद किया जा सकता है. इससे वीएम बंद हो जाता है. किसी वीएम को बंद करने पर, हाइपरवाइज़र मेमोरी को अपने-आप मिटा देता है और उसे होस्ट कर्नल को वापस कर देता है.

सामान्य KVM में, वीएमएम के पास मेहमान के तौर पर इस्तेमाल किए जा रहे सभी डिवाइसों की मेमोरी का ऐक्सेस होता है. pKVM की मदद से, मेहमान को मेमोरी देने पर, मेहमान की मेमोरी को होस्ट के फ़िज़िकल पते के स्पेस से अनमैप कर दिया जाता है. हालांकि, मेहमान की ओर से साफ़ तौर पर शेयर की गई मेमोरी इसका अपवाद है. जैसे, virtio डिवाइसों के लिए.

मेहमान के पते की जगह में मौजूद MMIO क्षेत्रों को मैप नहीं किया जाता. मेहमान के पास इन क्षेत्रों का ऐक्सेस नहीं है. इसलिए, वीएम के FD पर I/O इवेंट होता है. इस मैकेनिज़्म का इस्तेमाल वर्चुअल डिवाइसों को लागू करने के लिए किया जाता है. सुरक्षित मोड में, मेहमान को यह स्वीकार करना होगा कि उसके पते की जगह का इस्तेमाल MMIO के लिए किया जा रहा है. इसके लिए, उसे हाइपरकॉल का इस्तेमाल करना होगा, ताकि गलती से जानकारी लीक होने का जोखिम कम हो सके.

समय-निर्धारण

हर वर्चुअल सीपीयू को POSIX थ्रेड से दिखाया जाता है. इसे होस्ट Linux शेड्यूलर शेड्यूल करता है. थ्रेड, वीसीपीयू FD पर KVM_RUN ioctl को कॉल करता है. इससे हाइपरवाइज़र, मेहमान वीसीपीयू के कॉन्टेक्स्ट पर स्विच हो जाता है. होस्ट शेड्यूलर, गेस्ट कॉन्टेक्स्ट में बिताए गए समय को, उससे जुड़ी vCPU थ्रेड के इस्तेमाल किए गए समय के तौर पर मानता है. KVM_RUN तब दिखता है, जब कोई ऐसा इवेंट होता है जिसे वीएमएम को हैंडल करना होता है. जैसे, I/O, इंटरप्ट खत्म होना या vCPU रुक जाना. वीएमएम, इवेंट को मैनेज करता है और KVM_RUN को फिर से कॉल करता है.

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

सभी vCPU थ्रेड को किसी अन्य यूज़रस्पेस टास्क की तरह शेड्यूल किया जाता है. इसलिए, वे सभी स्टैंडर्ड QoS मेकेनिज़्म के दायरे में आते हैं. खास तौर पर, हर वीसीपीयू थ्रेड को फ़िज़िकल सीपीयू से जोड़ा जा सकता है, सीपीयूसेट में रखा जा सकता है, और यूटिलाइज़ेशन क्लैंपिंग का इस्तेमाल करके बढ़ाया या कम किया जा सकता है. साथ ही, इसकी प्राथमिकता/शेड्यूलिंग की नीति को बदला जा सकता है. इसके अलावा, और भी कई काम किए जा सकते हैं.

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

crosvm कई डिवाइसों के साथ काम करता है. इनमें ये डिवाइस शामिल हैं:

• कंपोज़िट डिस्क इमेज के लिए virtio-blk, सिर्फ़ पढ़ने या पढ़ने-लिखने के लिए
• होस्ट के साथ कम्यूनिकेट करने के लिए vhost-vsock
• virtio-pci को virtio ट्रांसपोर्ट के तौर पर इस्तेमाल करना
• pl030 रीयल टाइम क्लॉक (आरटीसी)
• सीरियल कम्यूनिकेशन के लिए 16550a UART

pVM फ़र्मवेयर

pVM फ़र्मवेयर (pvmfw), pVM पर एक्ज़ीक्यूट होने वाला पहला कोड है. यह किसी फ़िज़िकल डिवाइस के बूट रोम की तरह होता है. pvmfw का मुख्य मकसद, सुरक्षित बूट को बूटस्ट्रैप करना और pVM के यूनीक सीक्रेट को हासिल करना है. pvmfw का इस्तेमाल किसी खास ओएस के साथ नहीं किया जा सकता. जैसे, Microdroid. हालांकि, ऐसा तब तक किया जा सकता है, जब तक ओएस को crosvm से सहायता मिलती है और उसे सही तरीके से साइन किया गया हो.

pvmfw बाइनरी को उसी नाम के फ़्लैश पार्टिशन में सेव किया जाता है. इसे OTA का इस्तेमाल करके अपडेट किया जाता है.

डिवाइस बूट

pKVM की सुविधा वाले डिवाइस के बूट करने की प्रोसेस में, यहाँ दिया गया क्रम जोड़ा जाता है:

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

डिवाइस बूट होने के बाद, Microdroid दस्तावेज़ के बूट सीक्वेंस सेक्शन में दिए गए चरणों के मुताबिक, Microdroid बूट होता है.

pVM बूट

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

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

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