🥠 🎌 🐮 विभिन्न प्लेटफार्मों पर यूईएफआई कार्यान्वयन की समस्याएं और विशेषताएं 🍗 👔 🤦

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

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

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

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

प्लेटफ़ॉर्म डिपेंडेंस

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

यहां तक कि हमारे अभ्यास में, मैं इंटेल बे ट्रेल डी के साथ दो मिनी-कंप्यूटरों पर ठोकर खाने के लिए भाग्यशाली था और बोर्ड पर 32-बिट फर्मवेयर। मामला दुर्लभ है, लेकिन एक समय में इसने मॉड्यूल को तत्काल पुन: स्थापित करने के लिए आवश्यक बना दिया। वास्तव में, सवाल की तरह: क्या हम भविष्य में एक ही क्षमता के अधिक आधुनिक मंच के साथ मिलेंगे? और अगर हम मिलते हैं, तो कहाँ?

अगला चरण यह निर्धारित करना है कि कैसे एकीकृत किया जाए। मॉड्यूल को फर्मवेयर में बनाया गया है, फर्मवेयर बोर्ड पर एसपीआई चिप में स्थित है, और इंटेल एमई के साथ पीसीएच पास में स्थित है। और यहां सबसे दिलचस्प सवाल उठता है - वहां कैसे पहुंचे? एक "मगरमच्छ" के साथ अच्छा पुराना प्रोग्रामर - यह अच्छा है, यह विश्वसनीय है। यहां तक कि अगर आप अंत तक पकड़ नहीं करते हैं, तो आप हमेशा बोर्ड पर जलती हुई एल ई डी को देख सकते हैं, उनके पास प्रोग्रामर से पर्याप्त शक्ति है। यह लगभग त्रुटिपूर्ण रूप से काम करता है, कुछ पुराने एचपी मॉडल के अपवाद के साथ, जहां फर्मवेयर के साथ mikruha SOIC-16 इतना सुलभ है कि क्लिप को निचोड़ने की तुलना में एडॉप्टर को उसके पैरों को पकड़ना और मिलाप करना आसान है।

मुझे पता है कि हैबे पर ऐसे लोग हैं जिन्होंने फ्लैशर के लेखन में योगदान दिया है, उनके लिए अलग से धन्यवाद।

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

वह लिखता है और नहीं लिखता है

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

कभी-कभी IFR पार्सर लिखने की सुरक्षा से लड़ने में मदद करता है, जो छिपी हुई सेटिंग्स और चर पर पर्दा खोलता है। और कभी-कभी केवल एक कट्टर जम्पर मदद करता है, रिकॉर्डिंग की पहुंच या "एमई" को बंद करने की अनुमति देता है (यदि कोई प्रदान किया गया है, तो निश्चित रूप से)।

सिस्टम की जटिल प्रकृति

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

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

सर्वर-साइड हार्डवेयर एक ही समय में सरल और अधिक जटिल है। एक ओर, सर्वरों पर हमेशा BIOS को अपडेट करने और संशोधित करने के अतिरिक्त तरीके होते हैं, दूसरी ओर, इन समान BIOS में अनुकूलन की मात्रा बहुत अधिक होती है, क्योंकि वे सर्वर पर कंजूसी नहीं करते हैं और काफी कैपेसिटिव फ्लैश मेमोरी चिप्स स्थापित करते हैं, अक्सर उनका बैकअप लेते हैं।

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

मॉड्यूल की शुरूआत के बाद, सुरक्षा मॉड्यूल में से एक को अवरुद्ध करने के कारण लोड कसकर जम जाता है (वे सर्वर BIOS के स्वच्छंदता को ध्यान में नहीं रखते थे, जिनके साथ ऐसा नहीं होता है!)। IPMI के माध्यम से BIOS को वापस रोल करने के लिए बाध्य करने की क्षमता के अभाव में, हाथ स्वयं प्रोग्रामर के लिए पहुंच गया, लेकिन यह एक दुर्भाग्य था - SOIC-16 चिप के लिए मानक SOIC-8 क्लिप पर्याप्त नहीं था! ठीक है, ठीक है, क्योंकि सिद्धांत रूप में सर्वर बोर्ड में कनेक्टेड मीडिया से बैकअप लेने की क्षमता है, रूट में SUPER.ROM छवि को उठाकर। लेकिन यह तंत्र शुरू नहीं होता है, क्योंकि सिस्टम के अनुसार सब कुछ ठीक है, सब कुछ काम करता है, इसलिए, BIOS रोलबैक की आवश्यकता नहीं है! क्या करना है? .. कहानी सही क्लिप की तलाश में शहर के चारों ओर चल रही है, तारों की एक आपातकालीन पुन: टांका, हमारे लिए एक अतुलनीय क्रम में चीनी द्वारा धब्बा, और अंत में - एक चमकती।

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

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

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

ASRock H81M-DGS बोर्ड के साथ क्राफ्टवे BIOS बहुत स्वच्छंद साबित हुआ। तो, यह लटकाकर Ctrl Alt Del Del का जवाब देता है, जिसमें से केवल रीसेट इसे आउटपुट कर सकता है। शेल'ए में स्टार्टअप स्क्रिप्ट <स्टार्टअप.nsh> को लंघन करने के साथ समस्याएं थीं - पांच डिफ़ॉल्ट के बजाय चुनने के लिए एक दूसरा विभाजन। शायद ये समस्याएँ KSS के मालिकाना मॉड्यूल द्वारा किए गए संशोधन के कारण होती हैं, शायद यह मामला गलत "ME" है।

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

विभिन्न विक्रेताओं के बोर्डों के साथ काम करने के अनुभव को सारांशित करते हुए, आप इस निष्कर्ष पर आते हैं कि यह पता लगाना लगभग असंभव है कि ईएफआई स्तर पर आप अगले बोर्ड पर क्या आश्चर्य करेंगे, भले ही यह पहले से ही एक प्रसिद्ध मॉडल हो। यह एक प्रकार की लॉटरी है, क्योंकि कभी-कभी सिस्टम के बारे में जानकारी एकत्र करने के चरण में कठिनाइयां आ सकती हैं। शायद इसमें निर्विवाद शोध आदर्शवाद और निर्माता के विश्वास का हिस्सा है, क्योंकि ME v11 और v12 के साथ सबसे ताज़ा मदरबोर्ड के कुछ और कैसे हो सकते हैं जब उन पर पुराने संस्करणों का FPT या MEInfo चल रहा हो?

हार्डवेयर प्रोटोकॉल के साथ काम की समस्याएं

जब हम USB डिवाइस - ड्राइव और टोकन के साथ काम करना शुरू करते हैं तो कुछ समस्याएं सामने आती हैं। ऐसा अक्सर होता है क्योंकि बाह्य उपकरणों के साथ काम करने के लिए BIOS कोड ड्राइवरों का एक खतरनाक कॉकटेल और स्वतंत्र हार्डवेयर विक्रेता (IHV) से एक विशिष्ट परिधीय, चिपसेट निर्माता से कोड (हमारे मामले में, इंटेल से), BIOS निर्माता और कोड से कोड है। मदरबोर्ड के निर्माता से।

निम्नलिखित "दिलचस्प" स्थितियां

उत्पन्न हुई : टोकन "पता नहीं लगाया गया"। वहीं, इस पर एक एलईडी जलाई जाती है। सबसे अधिक संभावना है, मेजबान नियंत्रक यूएसबी डिवाइस की प्रारंभिक रीसेट प्रक्रिया के माध्यम से नहीं जाता है, अर्थात, बिजली की आपूर्ति की जाती है, लेकिन डी + और डी-लाइनों को बदलने के माध्यम से रीसेट सही ढंग से काम नहीं करता है, और इसके बिना, टोकन के साथ कोई और जोड़तोड़ व्यर्थ है।

कंप्यूटर शेल लोड करने से पहले जम जाता है (फिर से, एक टोकन जुड़ा हुआ है)। इस मामले में, एक टोकन के बिना, पीसी सामान्य रूप से शुरू होता है। लाइव, यह इस तरह दिखता है: कंप्यूटर शुरुआत के ठीक बाद दुर्घटनाग्रस्त होता है, जबकि टोकन कनेक्टर में चिपक जाता है। आप इसे बाहर निकालते हैं - लोडिंग अचानक जारी रहती है। कनेक्ट - फिर से लटका। UEFI में स्पष्ट समस्या है, और कोई केवल कारणों के बारे में अनुमान लगा सकता है।

स्थिति जब USB_IO इंटरफ़ेस को खोलना संभव नहीं है। शायद यह स्मार्ट कार्ड के साथ काम करने के लिए केवल इंटरफ़ेस के साथ जुड़ा हुआ है - यूएसबी सीसीआईडी। कुछ एएमआई ड्राइवर ने पहले से ही EFI_OPEN_PROTOCOL_BY_DRIVER पैरामीटर के साथ USB_IO खोला है। ड्राइवर का GUID के साथ एक प्रोटोकॉल है:

#define EFI_AMI_USB_CCID_PROTOCOL_GUID	 { 0x5FDEE00D, 0xDA40, 0x405A, { 0xB9, 0x2E, 0xCF, 0x4A, 0x80, 0xEA, 0x8F, 0x76} }
 // Workaround.      EFI_OPEN_PROTOCOL_BY_DRIVER,  ,     EFI_OPEN_PROTOCOL_GET_PROTOCOL.
 //
 // Open USB I/O Protocol
 //
 Status = gBS->OpenProtocol (
 ControllerHandle,
 &gEfiUsbIoProtocolGuid,
 (VOID **) &UsbIo,
 This->DriverBindingHandle,
 ControllerHandle,
 EFI_OPEN_PROTOCOL_BY_DRIVER
 );

 if (EFI_ACCESS_DENIED == Status)
 {		// AMI BIOS workaround (BindingStop will not be invoked)
	 Status = gBS->OpenProtocol(
		 ControllerHandle,
		 &gEfiUsbIoProtocolGuid,
		 (VOID **)&UsbIo,
		 This->DriverBindingHandle,
		 ControllerHandle,
		 EFI_OPEN_PROTOCOL_GET_PROTOCOL
	 );
 }

हालांकि, बाइंडिंगटॉप () नहीं कहा जाएगा, अर्थात डिवाइस निष्कर्षण घटना की निगरानी नहीं की जाती है, और ड्राइवर अमान्य हैंडल का उपयोग करने का प्रयास करेगा। यह HP Compaq Elite 8300 SFF PC और कुछ अन्य लोगों के साथ देखा गया था। यह अवांछित ड्राइवरों से या तो एक प्रकार का विक्रेता संरक्षण है, या एक नियमित विकास बग है। शायद USB CCID की दिशा में AMI लगातार कुछ कर रहा है, लेकिन हस्तक्षेप करने वाले ड्राइवर को अनलोड नहीं किया जा सकता है, क्योंकि यह USB HID, USB MassStorage के साथ एक ही AMI UHCI मॉड्यूल में स्थित है। UninstallInterface () के साथ, चीजें समान हैं।

या एक और दिलचस्प विशेषता। UEFI BIOS में से एक में, जहां टोकन का पता नहीं लगा था, USB_IO ने डिवाइस डिस्क्रिप्टर को पढ़ने की अनुमति दी, लेकिन EFI_INVALID_PARAMETER अगले UsbBulkTransfer () में वापस आ गया। इसके अलावा, यह केवल कुछ प्रकार के टोकन के साथ हुआ, बिल्कुल समान मापदंडों के साथ, अन्य ने पूरी तरह से काम किया।

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

वर्चुअलाइजेशन

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

VMware के बगीचे में एक और छोटा पत्थर - इसमें निर्मित FAT32 ड्राइवर केवल 8.3 संकेतन में फाइलों के निर्माण और संपादन का समर्थन करता है। यह स्पष्ट नहीं है कि ऐसा क्यों किया गया था, लेकिन यह एक सीमा है जिस पर स्पष्ट रूप से ध्यान देने की आवश्यकता है। यह संभावना है कि चालक के समान कार्यान्वयन को वास्तविक प्लेटफार्मों पर देखा जा सकता है, लेकिन अभी तक हम उन पर नहीं आए हैं।

दूसरी ओर, आभासी मशीनों में फर्मवेयर उपयोगिताओं, प्रोग्रामर, जंपर्स, असुविधाजनक चिप्स के साथ कोई नृत्य नहीं होता है। एक अलग ROM फ़ाइल, UEFITool और विन्यास फाइल में एक पंक्ति। लगभग एक मूर्ख।

अंततः

CHIPSEC से अनुरोध का एक टुकड़ा। वे ऐसे संस्कार कहां सिखाते हैं?

जैसा कि पहले ही उल्लेख किया गया है, यूईएफआई शेल में विकास और कार्यान्वयन एक आकर्षक और रचनात्मक प्रक्रिया है। आप हमेशा एक प्रसिद्ध क्षेत्र पर भी कुछ नया कर सकते हैं। एक तरफ, यह उत्साहजनक है कि मानक विकसित हो रहा है, दूसरी ओर, यह दुखद है कि उत्पादकों द्वारा इसका ठोस कार्यान्वयन बहुत "रचनात्मक" है।

मुख्य समस्याएँ और थीं:

फर्मवेयर विकसित करते समय UEFI विनिर्देश से विक्रेताओं का प्रस्थान।
कार्यान्वयन के दौरान कोड में त्रुटियां।
कोड में NDV, एकीकरण के दौरान पॉप-अप।

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

यह ध्यान दिया जाना चाहिए कि स्थिति धीरे-धीरे लेकिन निश्चित रूप से सही है, और मैं विश्वास करना चाहता हूं कि वह क्षण दूर नहीं है जब मानक का विकास एक काफी अनुमानित और बहुत ही सुखद प्रक्रिया बन जाएगा।

व्लादिमीर ओनिपचुक, गजिनफॉर्मस्वेस्क एलएलसी
के हार्डवेयर और सॉफ्टवेयर सुरक्षा उत्पादों के समूह के प्रमुख

विभिन्न प्लेटफार्मों पर यूईएफआई कार्यान्वयन की समस्याएं और विशेषताएं

प्लेटफ़ॉर्म डिपेंडेंस

सिस्टम की जटिल प्रकृति

हार्डवेयर प्रोटोकॉल के साथ काम की समस्याएं

वर्चुअलाइजेशन

अंततः

More articles: