ते लिनक्स बूट प्रक्रियेचे आधुनिकीकरण करण्याचा प्रस्ताव देतात

नवीन लिनक्स बूट मजबूतपणा आणि साधेपणावर लक्ष केंद्रित करून भविष्यात चांगले कार्य करेल.

लेनार्ट कवितेचे (Systemd चा निर्माता) ते ज्ञात केले अलीकडे बूट प्रक्रियेचे आधुनिकीकरण करण्याचा प्रस्ताव वितरण च्या लिनक्सचे, विद्यमान समस्यांचे निराकरण करण्याच्या उद्देशाने आणि कर्नलच्या सत्यतेची आणि अंतर्निहित प्रणाली वातावरणाची पुष्टी करून पूर्ण सत्यापित बूटची संस्था सुलभ करा.

प्रस्तावित बदल पर्यंत कमी केले जातात एकल सार्वत्रिक UKI प्रतिमा तयार करणे (युनिफाइड कर्नल इमेज) जे कर्नल प्रतिमा विलीन करते UEFI (UEFI बूट स्टब) वरून कर्नल लोड करण्यासाठी लिनक्स ड्रायव्हर आणि सिस्टम वातावरण initrd मेमरीमध्ये लोड केले जाते, FS आरोहित करण्यापूर्वी स्टेजवर प्रारंभिक आरंभासाठी वापरले जाते.

रॅमडिस्क प्रतिमेऐवजी initrd, संपूर्ण प्रणाली UKI मध्ये पॅक केली जाऊ शकते, RAM मध्ये लोड केलेले पूर्णपणे सत्यापित सिस्टम वातावरण तयार करण्यास परवानगी देते. UKI इमेज पीई फॉरमॅटमध्ये एक्झिक्यूटेबल फाइल म्हणून पॅक केलेली आहे, जी केवळ पारंपारिक बूटलोडरसह लोड केली जाऊ शकत नाही, परंतु थेट UEFI फर्मवेअरवरून देखील कॉल केली जाऊ शकते.

UEFI वरून कॉल करण्याची क्षमता डिजिटल स्वाक्षरीची वैधता आणि अखंडता तपासणी वापरण्यास अनुमती देते जे फक्त कर्नलच नाही तर initrd ची सामग्री देखील समाविष्ट करते. त्याच वेळी, पारंपारिक बूटलोडर्सच्या कॉल्ससाठी समर्थन अनेक कर्नल आवृत्त्या वितरीत करणे आणि नवीनतम आवृत्ती स्थापित केल्यानंतर नवीन कर्नलमध्ये समस्या आढळल्यास स्वयंचलितपणे कार्यरत कर्नलवर परत येण्यासारख्या वैशिष्ट्यांची बचत करण्यास अनुमती देते. अद्यतन.

सध्या, बहुतेक लिनक्स वितरण वापरतात साखळी "फर्मवेअर → डिजिटली स्वाक्षरी केलेले मायक्रोसॉफ्ट शिम लेयर → डिजिटली स्वाक्षरी केलेले वितरण GRUB बूटलोडर → डिजिटली स्वाक्षरी केलेले वितरण लिनक्स कर्नल → स्वाक्षरी न केलेले initrd वातावरण → FS रूट" सुरुवातीच्या प्रक्रियेत. initrd चेक गहाळ पारंपारिक वितरणात सुरक्षा समस्या निर्माण करते, कारण, इतर गोष्टींबरोबरच, हे वातावरण FS रूट डिक्रिप्ट करण्यासाठी की काढते.

initrd प्रतिमेचे सत्यापन समर्थित नाही, ही फाईल वापरकर्त्याच्या स्थानिक प्रणालीवर व्युत्पन्न केलेली असल्याने आणि वितरणाच्या डिजिटल स्वाक्षरीद्वारे प्रमाणित केली जाऊ शकत नाही, ज्यामुळे SecureBoot मोड वापरताना पडताळणी व्यवस्थापित करणे खूप कठीण होते (initrd सत्यापित करण्यासाठी, वापरकर्त्याने आपल्या की व्युत्पन्न करणे आणि त्या लोड करणे आवश्यक आहे. UEFI फर्मवेअर).

तसेच, विद्यमान बूट संस्था TPM PCR रजिस्टरमधील माहिती वापरण्यास परवानगी देत ​​नाही (प्लॅटफॉर्म कॉन्फिगरेशन रजिस्ट्री) शिम, ग्रब आणि कर्नल व्यतिरिक्त इतर वापरकर्ता स्पेस घटकांच्या अखंडतेवर नियंत्रण ठेवण्यासाठी. विद्यमान समस्यांपैकी, बूटलोडर अद्ययावत करण्याची गुंतागुंत आणि ऑपरेटिंग सिस्टमच्या जुन्या आवृत्त्यांसाठी टीपीएममध्ये की प्रवेश प्रतिबंधित करण्यात अक्षमता, जी अपडेट स्थापित केल्यानंतर अप्रासंगिक बनली आहे.

अंमलबजावणीची मुख्य उद्दिष्टे नवीन बूट आर्किटेक्चर:

• फर्मवेअर ते वापरकर्ता स्थानापर्यंतचे सर्व टप्पे समाविष्ट करून आणि डाउनलोड केलेल्या घटकांच्या वैधतेची आणि अखंडतेची पुष्टी करणारी पूर्णतः सत्यापित डाउनलोड प्रक्रिया प्रदान करा.
• नियंत्रित संसाधने TPM PCR नोंदणीशी जोडणे मालकांद्वारे वेगळे करणे.
• कर्नल बूट, इनिटर्ड, कॉन्फिगरेशन आणि स्थानिक सिस्टम आयडीवर आधारित पीसीआर मूल्यांची प्रीकॉम्प्युट करण्याची क्षमता.
• सिस्टमच्या मागील असुरक्षित आवृत्तीवर परत येण्याशी संबंधित रोलबॅक हल्ल्यांपासून संरक्षण.
• अद्यतनांची विश्वासार्हता सुलभ करा आणि सुधारा.
• OS अपग्रेडसाठी समर्थन ज्यांना स्थानिक पातळीवर TPM-संरक्षित संसाधने पुन्हा लागू करणे किंवा तरतूद करणे आवश्यक नाही.
• ऑपरेटिंग सिस्टम आणि बूट कॉन्फिगरेशनच्या शुद्धतेची पुष्टी करण्यासाठी रिमोट प्रमाणपत्रासाठी सिस्टम तयार करणे.
• विशिष्ट बूट टप्प्यांवर संवेदनशील डेटा संलग्न करण्याची क्षमता, उदाहरणार्थ TPM मधून FS रूटसाठी एनक्रिप्शन की काढणे.
• रूट विभाजनासह ड्राइव्ह डिक्रिप्ट करण्यासाठी की अनलॉक करण्यासाठी सुरक्षित, स्वयंचलित आणि मूक प्रक्रिया प्रदान करा.
• TPM 2.0 स्पेसिफिकेशनला समर्थन देणार्‍या चिप्सचा वापर, TPM शिवाय सिस्टमवर परत येण्याच्या क्षमतेसह.

आवश्यक बदल नवीन आर्किटेक्चर अंमलात आणण्यासाठी आधीच systemd codebase मध्ये समाविष्ट आहेत आणि systemd-stub, systemd-measure, systemd-cryptenroll, systemd-cryptsetup, systemd-pcrphase, आणि systemd-creds सारख्या घटकांना प्रभावित करते.

शेवटी आपल्याला त्याबद्दल अधिक जाणून घेण्यात स्वारस्य असल्यास, आपण मधील तपशील तपासू शकता खालील दुवा.