लिनक्स और सिक्योर बूट। एक त्रुटि जिसे हम दोहरा नहीं सकते

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

लिनक्स और सुरक्षित बूट

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

समाधान Microsoft के साथ कुछ Linux वितरणों द्वारा प्राप्त किया गया है यह था कि इस कंपनी ने एक बाइनरी के हस्ताक्षर को स्वीकार कर लिया था जो प्रत्येक वितरण के बूट लोडर को लॉन्च करने का प्रभारी होगा. इन बायनेरिज़ को समुदाय के लिए उपलब्ध कराया गया था।

इसके बाद, लिनक्स फाउंडेशन एक सामान्य समाधान शुरू करेगा जिसे सभी वितरणों द्वारा अपनाया जा सकता है।

एक बेहतर समाधान की तलाश में, एक Red Hat डेवलपर ने लिनुस टॉर्वाल्ड्स को निम्नलिखित सुझाव दिए:

हाय लिनुस,

क्या आप कृपया इस पैच सेट को शामिल कर सकते हैं?

एक फ़ंक्शन प्रदान करता है जिसके द्वारा सुरक्षित बूट मोड में चल रहे कर्नेल में कुंजियों को गतिशील रूप से जोड़ा जा सकता है। ऐसी स्थिति में एक कुंजी को लोड करने की अनुमति देने के लिए, हमें आवश्यक है कि नई कुंजी उस कुंजी द्वारा हस्ताक्षरित हो जो हमारे पास पहले से है (और जिस पर हमें भरोसा है), जहां हमारे पास "पहले से ही" कुंजी शामिल हो सकती है जो कर्नेल में एम्बेडेड हो सकती है, वे UEFI डेटाबेस और क्रिप्टोग्राफ़िक हार्डवेयर के हैं।

अब "keyctl add" पहले से ही इस तरह हस्ताक्षरित X.509 प्रमाणपत्रों को संभाल लेगा, लेकिन Microsoft की हस्ताक्षर सेवा केवल निष्पादन योग्य EFI PE बायनेरिज़ पर हस्ताक्षर करेगी।

हमें उपयोगकर्ता को BIOS में रीबूट करने, कुंजी जोड़ने और फिर वापस स्विच करने की आवश्यकता हो सकती है, लेकिन कुछ परिस्थितियों में हम कर्नेल के चलने के दौरान ऐसा करने में सक्षम होना चाहते हैं।

जिस तरह से हम इसे ठीक करने के लिए आए हैं, वह एक EFI PE बाइनरी में ".keylist" नामक अनुभाग में कुंजी युक्त X.509 प्रमाणपत्र को एम्बेड करना है और फिर Microsoft द्वारा हस्ताक्षरित बाइनरी प्राप्त करना है।

लिनुस शब्द

लिनुस की प्रतिक्रिया (आइए याद रखें कि अन्य लोगों के साथ संबंधों में अपने दृष्टिकोण पर पुनर्विचार करने के लिए उनके आध्यात्मिक वापसी से पहले), निम्नलिखित था:

सूचना: निम्नलिखित पाठ में अपवित्रता शामिल है

दोस्तों, यह मुर्गा चूसने की प्रतियोगिता नहीं है।

यदि आप पीई बायनेरिज़ का उपयोग करना चाहते हैं, तो कृपया जारी रखें। यदि Red Hat Microsoft के साथ अपने संबंध को गहरा करना चाहता है, तो यह *आपकी * समस्या है। इसका उस कर्नेल से कोई लेना-देना नहीं है जिसे मैं बनाए रखता हूं. आपके लिए एक हस्ताक्षर इंजन होना आसान है जो पीई बाइनरी को पार्स करता है, हस्ताक्षरों को सत्यापित करता है, और परिणामी कुंजियों को आपकी अपनी कुंजी से साइन करता है। कोड, भगवान के प्यार के लिए, पहले से ही लिखा है, यह शामिल करने के लिए उस लानत अनुरोध में है।

मुझे क्यों चिंता करनी चाहिए? कर्नेल को कुछ बेवकूफों की परवाह क्यों करनी चाहिए "हम केवल पीई बाइनरी पर हस्ताक्षर करते हैं" बेवकूफ? हम X.509 का समर्थन करते हैं, जो हस्ताक्षर करने का मानक है।

यह उपयोगकर्ता स्तर पर किया जा सकता है। कर्नेल में ऐसा करने का कोई बहाना नहीं है।

लिनस

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

वास्तविकता यह है कि जब माइक्रोसॉफ्ट को एक लड़ाई का सामना करना पड़ता है, तो उसे मानकों का पालन करने के लिए मजबूर होना पड़ता है. यह तब हुआ जब वह सिल्वरलाइट के साथ विफल हो गई और उसे HTML 5 वेब मानक अपनाने के लिए मजबूर किया गया। यह तब हुआ जब उसे वेब रेंडरिंग इंजन विकास और क्रोमियम पर आधार एज को छोड़ना पड़ा।

हमें यह भी नहीं भूलना चाहिए कि प्रोग्रामर्स को आकर्षित करने के लिए इसमें विंडोज़ पर लिनक्स चलाने की क्षमता से कम कुछ भी शामिल नहीं था।

लिनक्स वितरण पहले से कहीं बेहतर स्थिति में है ताकि उपयोगकर्ताओं को पूरी तरह कार्यात्मक हार्डवेयर का उपयोग जारी रखने का विकल्प प्रदान किया जा सके।