الاسم¶

systemd-stub, sd-stub, linuxx64.efi.stub, linuxia32.efi.stub, linuxaa64.efi.stub - نواة إقلاع UEFI بسيطة

موجز¶

/usr/lib/systemd/boot/efi/linuxx64.efi.stub

/usr/lib/systemd/boot/efi/linuxia32.efi.stub

/usr/lib/systemd/boot/efi/linuxaa64.efi.stub

ESP/.../foo.efi.extra.d/*.addon.efi

ESP/.../foo.efi.extra.d/*.cred

ESP/.../foo.efi.extra.d/*.raw

ESP/.../foo.efi.extra.d/*.sysext.raw

ESP/.../foo.efi.extra.d/*.confext.raw

ESP/loader/addons/*.addon.efi

ESP/loader/credentials/*.cred

الوصف¶

systemd-stub (المخزن في ملفات حسب المعمارية linuxx64.efi.stub, linuxia32.efi.stub, linuxaa64.efi.stub على القرص) هو نواة إقلاع UEFI بسيطة. نواة إقلاع UEFI تُلحق بصورة ثنائية نواة لينكس، وهي قطعة كود تعمل في بيئة برمجيات UEFI الثابتة قبل الانتقال إلى بيئة نواة لينكس. تضمن نواة إقلاع UEFI أن نواة لينكس قابلة للتنفيذ كملف ثنائي UEFI عادي، وقادرة على القيام باستعدادات متنوعة قبل تحويل النظام إلى عالم لينكس.

تبحث نواة إقلاع UEFI عن موارد متنوعة لاستدعاء النواة داخل الملف الثنائي PE الخاص بـ UEFI نفسه. يسمح هذا بدمج موارد متنوعة داخل صورة ثنائية PE واحدة ("صورة نواة موحدة" أو "UKI" للاختصار)، والتي يمكن توقيعها بعد ذلك عبر UEFI SecureBoot ككل، لتغطية جميع الموارد الفردية دفعة واحدة. تحديدًا، قد تتضمن الأقسام PE التالية:

•قسم ".linux" يحتوي على صورة نواة لينكس بصيغة ELF. هذا القسم مطلوب.

•قسم اختياري ".osrel" يحتوي على معلومات إصدار نظام التشغيل، أي محتويات ملف os-release(5) لنظام التشغيل الذي تنتمي إليه النواة.

•قسم اختياري ".cmdline" يحتوي على سطر أوامر النواة لتمريره إلى النواة المستدعاة.

•قسم اختياري ".initrd" يحتوي على initrd.

•قسم اختياري ".ucode" يحتوي على initrd يحتوي على برمجيات دقيقة، ليُسلّم إلى النواة قبل أي initrd آخر. يجب ألا يكون هذا initrd مضغوطًا.

•قسم اختياري ".splash" يحتوي على صورة (بتنسيق Windows .BMP) لعرضها على الشاشة قبل استدعاء النواة.

•قسم اختياري ".dtb" يحتوي على DeviceTree ثنائي مُجمّع.

•صفر أو أكثر من مقاطع ".dtbauto". سيستخدم systemd-stub دائمًا أول مقطع مطابق. يُجرى المطابقة بأخذ أول سلسلة compatible لـ DeviceTree المقدمة من البرنامج الثابت في جداول التهيئة ومقارنتها بأول سلسلة compatible من كل مقطع من مقاطع ".dtbauto". إذا لم يقدم البرنامج الثابت DeviceTree، تُجرى المطابقة باستخدام مقطع .hwids بدلاً من ذلك. بعد اختيار مقطع ".hwids" (انظر الوصف أدناه)، ستُستخدم سلسلة compatible من ذلك المقطع لإجراء نفس إجراء المطابقة. إذا وُجد تطابق، سيُحمَّل ذلك المقطع ".dtbauto" وسيتجاوز .dtb إن وُجد.

•صفر أو أكثر من أقسام ".hwids" تحتوي على معرفات الأجهزة للآلات المطابقة لـ DeviceTrees. يستخدم systemd-stub بيانات SMBIOS لحساب معرفات الأجهزة للآلة (وفقًا لـ المواصفات[1])، ثم يحاول العثور على أي منها في كل قسم من أقسام ".hwids". يُستخدم القسم المطابق الأول.

•قسم اختياري ".uname" يحتوي على معلومات إصدار النواة، أي مخرجات uname -r للنواة المضمنة في قسم ".linux".

•قسم اختياري ".sbat" يحتوي على بيانات تعريف إلغاء SBAT[2].

•قسم اختياري ".pcrsig" يحتوي على مجموعة من التوقيعات التشفيرية لقيم TPM2 PCR المتوقعة بعد إقلاع النواة، بتنسيق JSON. هذا مفيد لتنفيذ سياسات TPM2 التي تربط تشفير القرص وما شابه ذلك بالنوى الموقعة بمفتاح محدد.

•قسم اختياري ".pcrpkey" يحتوي على مفتاح عام بتنسيق PEM يطابق بيانات التوقيع في قسم ".pcrsig".

في UKI أساسي، تظهر الأقسام المذكورة أعلاه مرة واحدة على الأكثر، باستثناء أقسام ".dtbauto" و".hwids". في UKI متعدد الملفات الشخصية، توجد مجموعات متعددة من هذه الأقسام في ملف واحد وتشكل "ملفات شخصية"، يمكن اختيار أحدها عند الإقلاع. لهذا، يُعرف قسم PE ".profile" لاستخدامه كفاصل بين مجموعات الأقسام. قد يحتوي قسم ".profile" نفسه على معلومات وصفية حول القسم، ويتبع بنية مشابهة لمحتويات قسم ".osrel". لمزيد من التفاصيل حول UKIs متعدد الملفات الشخصية، انظر أدناه.

إذا كان UEFI SecureBoot مفعّلاً وكان قسم ".cmdline" موجودًا في الصورة المنفذة، تُتجاهل أي محاولات لتجاوز سطر أوامر النواة بتمرير واحد كمعاملات استدعاء للملف الثنائي EFI. لذلك، للسماح بتجاوز سطر أوامر النواة، إما تعطيل UEFI SecureBoot، أو عدم تضمين قسم PE لسطر أوامر النواة في ملف صورة النواة. إذا قُبل سطر أوامر عبر معاملات استدعاء EFI للملف الثنائي EFI، يُقاس في TPM PCR 12 (إذا كان TPM موجودًا).

إذا كان DeviceTree مضمنًا في قسم ".dtb"، فإنه يستبدل DeviceTree موجودًا في جدول تهيئة EFI المقابل. يطلب systemd-stub من البرامج الثابتة عبر "EFI_DT_FIXUP_PROTOCOL" إصلاحات خاصة بالجهاز لـ DeviceTree.

تُقاس محتويات 11 من هذه الأقسام الـ12 في TPM PCR 11. لا يُستخدم بخلاف ذلك، وبالتالي يمكن حساب النتيجة مسبقًا دون جهد كبير. لا يُدرج قسم ".pcrsig" في هذا القياس PCR، لأنه من المفترض أن يحتوي على توقيعات لمخرجات عملية القياس، وبالتالي لا يمكن أن يكون مدخلاً لها أيضًا. إذا كان UKI يحتوي على ملفات شخصية متعددة، تُقاس فقط أقسام PE للملف الشخصي المحدد (وتلك الخاصة بالملف الشخصي الأساسي، إلا إذا تم تجاوزها).

إذا كان غير صفري، يُقاس الملف الشخصي الرقمي المحدد في PCR 12.

عند وجود قسمي ".pcrsig" و/أو ".pcrpkey" في صورة نواة موحدة، يتم تمرير محتوياتهما إلى النواة المُشغَّلة في أرشيف initrd اصطناعي، حيث يتم وضعهما في الملفين /.extra/tpm2-pcr-signature.json و/.extra/tpm2-pcr-public-key.pem. عادةً، يضمن السطر tmpfiles.d(5) نسخهما إلى /run/systemd/tpm2-pcr-signature.json و/run/systemd/tpm2-pcr-public-key.pem، حيث يظلان متاحين حتى بعد انتقال النظام من بيئة initrd إلى نظام ملفات المضيف. ستستخدم أدوات مثل systemd-cryptsetup@.service(8) وsystemd-cryptenroll(1) وsystemd-creds(1) تلقائيًا الملفات الموجودة ضمن هذه المسارات لفتح الموارد المحمية (التخزين المشفر أو بيانات الاعتماد) أو ربط التشفير بنواة النظام التي تم تشغيلها.

لمزيد من التفاصيل حول مفهوم UKI، انظر مواصفات UKI[3].

الملفات المساعدة¶

يجمع systemd-stub UEFI boot stub آليًا ثلاثة أنواع من الملفات المساعدة الاختيارية الموضوعة في أدلة الإسقاط على نفس القسم مثل ثنائي EFI، ويولد آليًا أرشيفات cpio initrd منها، ويمررها إلى النواة. تحديدًا:

•بالنسبة لثنائي نواة يُسمى foo.efi، يبحث عن ملفات باللاحقة .cred في دليل يُسمى foo.efi.extra.d/ بجانبه. إذا استخدم ثنائي النواة عدادًا لغرض تقييم الإقلاع الآلي[4]، يُتجاهل هذا العداد. على سبيل المثال، يبحث foo+3-0.efi في الدليل foo.efi.extra.d/. يُنشأ أرشيف cpio من جميع الملفات التي وُجدت بهذه الطريقة، ويوضع في دليل /.extra/credentials/ من تسلسل ملفات initrd. يمكن لـ initrd الرئيسي الوصول إليها بعد ذلك في هذا الدليل. يُفترض استخدام هذا لتخزين بيانات استيثاق مساعدة ومشفرة وموثقة للاستخدام مع LoadCredentialEncrypted= في قسم نظام UEFI. انظر systemd.exec(5) و systemd-creds(1) للتفاصيل حول بيانات الاستيثاق المشفرة. يُقاس أرشيف cpio المُنشأ في TPM PCR 12 (إذا وُجد TPM).

•بالمثل، تُحزم الملفات foo.efi.extra.d/*.sysext.raw في أرشيف cpio وتوضع في دليل /.extra/sysext/ من تسلسل ملفات initrd. يُفترض استخدام هذا لتمرير صور إضافية لامتدادات النظام إلى initrd. انظر systemd-sysext(8) للتفاصيل حول صور امتدادات النظام. يُقاس أرشيف cpio المُنشأ الذي يحتوي صور امتدادات النظام هذه في TPM PCR 13 (إذا وُجد TPM).

•بالمثل، تُحزم الملفات foo.efi.extra.d/*.confext.raw في أرشيف cpio وتوضع في دليل /.extra/confext/ من تسلسل ملفات initrd. يُفترض استخدام هذا لتمرير صور إضافية لامتدادات التهيئة إلى initrd. انظر systemd-confext(8) للتفاصيل حول صور امتدادات التهيئة. يُقاس أرشيف cpio المُنشأ الذي يحتوي صور امتدادات التهيئة هذه في TPM PCR 12 (إذا وُجد TPM).

•بالمثل، يتم تحميل الملفات foo.efi.extra.d/*.addon.efi والتحقق منها كثنائيات PE، ويتم تحميل أقسام محددة منها. تُستخدم الإضافات لتمرير معاملات إضافية لسطر أوامر النواة (قسم ".cmdline")، أو كتل DeviceTree (قسم ".dtb")، أو initrds إضافية (قسم ".initrd")، وتحديثات الميكروكود (قسم ".ucode"). تسمح الإضافات بتمرير هذه الموارد بغض النظر عن إصدار النواة الذي يتم إقلاعه، مما يسمح مثلاً لموردي المنصات بشحن تهيئة خاصة بالمنصة.

في حالة تمكين الإقلاع الآمن، سيتم التحقق من صحة هذه الملفات باستخدام المفاتيح في UEFI DB، أو DB الخاص بـ Shim، أو MOK الخاص بـ Shim، ولن يتم تحميلها إلا إذا نجح الفحص. بالإضافة إلى ذلك، إذا احتوى كل من الإضافة وUKI على قسم ".uname"، فسيتم رفض الإضافة إذا لم يتطابقا تمامًا. يُوصى دائمًا بإضافة قسم ".sbat" إلى جميع الإضافات الموقعة، بحيث يمكن إبطالها بتحديث سياسة SBAT، دون الحاجة إلى حظر عبر DBX/MOKX. ستضيف أداة ukify(1) سياسة SBAT افتراضيًا إذا لم يتم تمرير أي منها عند بناء الإضافات. لمزيد من المعلومات حول SBAT، انظر توثيق Shim[2].

يتم فرز ملفات الإضافة وتحميلها وقياسها في TPM PCR 12 (إذا كان TPM موجودًا) وإلحاقها بسطر أوامر النواة. يتم سرد خيارات سطر أوامر UKI أولاً، ثم الخيارات من الإضافات في /loader/addons/*.addon.efi، وأخيرًا الإضافات الخاصة بـ UKI. يتم تحميل كتل Device tree وقياسها باتباع نفس الخوارزمية. يتم تمرير إضافات الميكروكود إلى النواة بترتيب عكسي (إضافات UKI الخاصة، الإضافات العالمية، القسم المضمن في UKI). هذا لأن برنامج تشغيل تحديث الميكروكود يتوقف عند أول اسم ملف مطابق. يتم دائمًا تحميل الإضافات بنفس الترتيب بناءً على اسم الملف، بحيث، مع نفس مجموعة الإضافات، يمكن توقع نفس مجموعة القياسات في PCR12. ومع ذلك، لاحظ أن اسم الملف غير محمي بتوقيع PE، وبالتالي يمكن للمهاجم الذي لديه وصول كتابة إلى ESP إعادة تسمية هذه الملفات لتغيير الترتيب الذي يتم تحميلها به، بطريقة قد تغير وظائف النواة، حيث قد تعتمد بعض الخيارات على الترتيب. إذا قمت بتوقيع مثل هذه الإضافات، يجب الانتباه إلى قيم PCR12 واستخدام خدمة إثبات بحيث يمكن اكتشاف الاستخدام غير السليم لإضافاتك الموقعة والتعامل معه باستخدام إحدى آليات الإبطال المذكورة أعلاه.

•يتم تعبئة الملفات /loader/credentials/*.cred في أرشيف cpio ووضعها في دليل /.extra/global_credentials/ من تسلسل ملفات initrd. يُفترض استخدام هذا لتمرير بيانات استيثاق إضافية إلى initrd، بغض النظر عن إصدار النواة الذي يتم إقلاعه. يتم قياس أرشيف cpio المُنشأ في TPM PCR 12 (إذا كان TPM موجودًا).

•بالإضافة إلى ذلك، يتم تحميل الملفات /loader/addons/*.addon.efi والتحقق منها كثنائيات PE، ويتم تحليل الأقسام ".cmdline" و".dtb" و".initrd" و".ucode" منها. يُفترض استخدام هذا لتمرير معاملات إضافية لسطر الأوامر، وكتل DeviceTree، وinitrds، وتحديثات الميكروكود إلى النواة، بغض النظر عن إصدار النواة الذي يتم إقلاعه.

يمكن استخدام هذه الآليات لتعيين المعلمات وتوسيع صور initrd الموثوقة (أي الموقعة) والثابتة بطريقة آمنة إلى حد معقول: حيث يتم تسجيل جميع البيانات التي تحتوي عليها في سجلات PCR الخاصة بـ TPM. عند الوصول إليها، يجب التحقق من صحتها بشكل إضافي: في حالة بيانات الاعتماد، عن طريق تشفيرها/المصادقة عليها عبر TPM، كما هو موضح في systemd-creds encrypt -T (انظر systemd-creds(1) للحصول على التفاصيل)؛ وفي حالة صور امتداد النظام، عن طريق استخدام صور Verity الموقعة.

UKIS متعدد التشكيلات¶

في العديد من السياقات، من المفيد السماح باستدعاء وحدة UKI واحدة في أوضاع متعددة ومختلفة (أو ”ملفات تعريف“) دون المساس بـ سلامة التشفير والقياسات وما إلى ذلك في عملية التمهيد. على سبيل المثال، قد يوفر UKI واحد ثلاثة ملفات تعريف مميزة: ملف تعريف التمهيد العادي ، وملف تعريف يستدعي عملية ”إعادة الضبط إلى إعدادات المصنع“، وملف تعريف يقوم بالتمهيد إلى وضع هدف التخزين (كما في systemd-storagetm.service(8)). سيستخدم كل ملف تعريف بعد ذلك نفس أقسام ”.linux“ و ”.initrd“، ولكن سيكون له قسم ”.cmdline“ منفصل. على سبيل المثال، سيقوم الملفان الأخيران بتوسيع سطر أوامر النواة العادي بـ "systemd.unit=factory-reset.target” أو “rd.systemd.unit=storagetm.target".

قد يدعم UKI واحد عدة ملفات تعريف عن طريق قسم PE الخاص ".profile". يعمل هذا القسم كفاصل بين أقسام PE الخاصة بملفات التعريف الفردية. وبالتالي، قد تظهر أقسام PE ”.profile“ عدة مرات في UKI واحد، وقد تظهر أقسام PE الأخرى المذكورة أعلاه عدة مرات أيضًا، في حالة استخدام ”.profile“، ولكن مرة واحدة فقط قبل قسم ”.profile“ الأول، ومرة واحدة بين كل زوج لاحق، ومرة واحدة بعد آخر ظهور لـ ”.profile“. تُعتبر الأقسام المدرجة قبل أول ”.profile“ التشكية ”الأساسية“ لـ UKI. ثم يقدم كل قسم ”.profile“ تشكيلة جديدة، تُرقم بدءًا من الصفر. أقسام PE التي تلي كل ”.profile“ خاصة بذلك الملف الشخصي. عند التمهيد إلى ملف التشكيلة محدد، تستخدم أقسام التشكيلة الأساسية بالاشتراك مع أقسام التشكيلة المحددة: إذا عٌرف نفس القسم في كليهما، فإن القسم الخاص بالتشكيلة يتجاوز إصدار التشكيلة الأساسية، وإلا يُستخدم أقسام الملف التعريفي الأساسي.

يُعتبر عنوان UKI الذي لا يحتوي على ”.profile“ مكافئًا للعنوان الذي يحتوي فقط على ”.profile“ واحد، باعتباره يحتوي على ملف تعريف واحد فقط ”@0“.

فيما يلي مثال بسيط لأقسام UKI متعددة الملامح، مستوحى من الإعداد المقترح أعلاه:

Table 1. Multi-Profile UKI Example

Section	Profile
".linux"	Base profile
".osrel"
".cmdline"
".initrd"
".profile"	الملف التعريفي @0
".profile"	الملف التعريفي @1
".cmdline"
".profile"	الملف التعريفي @2
".cmdline"

قائمة الأقسام أعلاه تُعرّف ثلاثة ملفات تعريفية. الأقسام الأربعة الأولى تُشكّل الملف التعريفي الأساسي. يُقدّم قسم ".profile" بعد ذلك الملف التعريفي @0. لا يتجاوز هذا القسم أي أقسام (أو يُضيف أيًا منها) من القسم الأساسي، لذا يتبعه فورًا قسم ".profile" آخر يُقدّم الملف التعريفي @1. يتجاوز هذا الملف التعريفي سطر أوامر النواة. أخيرًا، يُعرّف القسمان الأخيران الملف التعريفي @2، مع تجاوز سطر الأوامر مرة أخرى. (لاحظ أنه في هذا المثال، يمكن نقل أول ".cmdline" أيضًا خلف أول ".profile" بنفس التأثير. للحفاظ على قابلية التوسع بشكل جيد، من المحتمل أن يكون من الجيد الاحتفاظ بسطر الأوامر العام في القسم الأساسي بدلاً من الملف التعريفي 0، في حال رغبت ملفات تعريفية مضافة لاحقًا في إعادة استخدامه.)

يمكن التحكم في الملف التعريفي للإقلاع عبر سطر أوامر UKI الخاص: إذا بدأت الوسيطة الأولى بـ "@"، متبوعة برقم صحيح موجب بالنظام العشري، فإنها تختار الملف التعريفي للإقلاع إليه. إذا لم تُحدد الوسيطة الأولى بهذه الطريقة، فسيُقلع UKI آليًا إلى الملف التعريفي 0.

قد يحتوي قسم ".profile" على معلومات وصفية حول الملف الشخصي. يتبع تنسيقًا مشابهًا لـ ".osrel" (أي قائمة تشبه كتلة تعيين متغيرات البيئة من سلاسل مفصولة بأسطر جديدة). حاليًا، يُعرف حقلان: "ID=" يُفترض أن يحمل سلسلة تعريف قصيرة تحدد الملف الشخصي (مثل "ID=factory-reset"). يجب أن يحتوي "TITLE=" على سلسلة قابلة للقراءة البشرية قد تظهر في إدخال قائمة الإقلاع لهذا الملف الشخصي (مثل "TITLE='إعادة ضبط المصنع لهذا الجهاز'").

ملاحظات TPM PCR¶

لاحظ أنه عند استدعاء نواة موحدة تستخدم systemd-stub، سيقيسها البرنامج الثابت ككل إلى TPM PCR 4، مُغطيًا جميع الموارد المضمنة، مثل كود الدعامة نفسه، النواة الأساسية، initrd المضمن وسطر أوامر النواة (انظر أعلاه للحصول على قائمة كاملة)، بما في ذلك جميع ملفات UKI التعريفية.

لاحظ أيضًا أنه عندما يقيس systemd-stub قسم PE، فإنه سيقيس عدد البايتات التي يشغلها القسم في الذاكرة (VirtualSize) وليس عدد البايتات التي يشغلها القسم على القرص (SizeOfRawData). هذا يعني أنه إذا كان الحجم في الذاكرة أكبر من الحجم على القرص، فسينتهي systemd-stub بقياس أصفار إضافية. لتجنب حدوث ذلك، يُوصى بالتأكد من أن الحجم في الذاكرة لكل قسم يُقاس بواسطة systemd-stub يكون دائمًا أصغر من أو يساوي الحجم على القرص. يضمن ukify آليًا حدوث ذلك عند بناء UKIs أو الإضافات.

لاحظ أيضًا أن نواة لينكس ستقيس جميع initrds التي تستقبلها إلى TPM PCR 9. هذا يعني أن كل نوع من initrd (للملف التعريفي UKI المحدد) قد يُقاس مرتين أو ثلاث مرات: initrds المضمنة في صورة النواة ستُقاس إلى PCR 4 و PCR 9 و PCR 11؛ initrd المُصنّع من بيانات الاعتماد (والمُصنّع من امتدادات التهيئة) سيُقاس إلى كل من PCR 9 و PCR 12؛ initrd المُصنّع من امتدادات النظام سيُقاس إلى كل من PCR 4 و PCR 9. دعنا نلخص موارد نظام التشغيل و PCRs التي تُقاس إليها:

جدول 2. ملخص PCR لموارد نظام التشغيل

مورد نظام التشغيل	PCR القياس
كود systemd-stub (نقطة الدخول للثنائي PE الموحد)	4
كود النواة الأساسي (مضمن في الثنائي PE الموحد)	4 + 11
معلومات إصدار نظام التشغيل (مضمنة في الثنائي PE الموحد)	4 + 11
initrd الرئيسي (مضمن في الثنائي PE الموحد)	4 + 9 + 11
initrd للبرنامج الصغير (مضمن في الثنائي PE الموحد)	4 + 9 + 11
سطر أوامر النواة المبدئي (مضمن في الثنائي PE الموحد)	4 + 11
سطر أوامر النواة المُستبدَل	12
شاشة الإقلاع (مضمنة في ثنائي PE الموحد)	4 + 11
توقيع TPM2 PCR بصيغة JSON (مضمن في ثنائي PE الموحد، مُصنَّع في initrd)	4 + 9
مفتاح TPM2 PCR العام بصيغة PEM (مضمن في ثنائي PE الموحد، مُصنَّع في initrd)	4 + 9 + 11
بيانات الاعتماد (initrd مُصنَّع من ملفات مرافقة)	9 + 12
إضافات النظام (initrd مُصنَّع من ملفات مرافقة)	9 + 13
إضافات التهيئة (initrd مُصنَّع من ملفات مرافقة)	9 + 12
الملف الشخصي المُحدَّد ما لم يكن صفراً	12

متغيرات EFI¶

المتغيرات التالية لـ EFI تُعرَّف وتُضبط وتُقرأ بواسطة systemd-stub، تحت UUID البائع "4a67b082-0a4c-41cf-b6c7-440b29bb8c4f"، للاتصال بين كعب الإقلاع والنظام التشغيلي:

LoaderDevicePartUUID

يحتوي على UUID القسم للقسم الذي بدأ منه محمل الإقلاع في الإقلاع الحالي (عادةً قسم نظام EFI). إذا ضُبِط بالفعل بواسطة محمل الإقلاع، فلن يتأثر هذا بواسطة systemd-stub. إذا لم يُضبَط بعد، فسيُضبَط إلى UUID القسم للقسم الذي بدأت منه النواة الموحدة، لدعم الأنظمة التي تُقلع مباشرةً في صورة نواة موحدة، متجاوزةً أي محمل إقلاع. يستخدم systemd-gpt-auto-generator(8) هذه المعلومات للعثور آلياً على القرص المُقلَع منه، لاكتشاف أقسام أخرى مختلفة على نفس القرص آلياً.

أُضيف في الإصدار 224.

LoaderFirmwareInfo، LoaderFirmwareType

معلومات موجزة عن البرامج الثابتة. استخدم bootctl(1) لعرض هذه البيانات.

أُضيف في الإصدار 250.

LoaderImageIdentifier

مسار نظام الملفات إلى الملف التنفيذي EFI لمحمل الإقلاع للإقلاع الحالي، نسبياً إلى دليل جذر القسم (أي نسبياً إلى القسم المُشار إليه بواسطة LoaderDevicePartUUID، انظر أعلاه). إذا لم يُضبَط بعد، فسيُضبَط إلى مسار نظام الملفات للملف التنفيذي EFI للنواة الموحدة المُقلَعة، لدعم الأنظمة التي تُقلع مباشرةً في صورة نواة موحدة، متجاوزةً أي محمل إقلاع. استخدم bootctl(1) لعرض هذه البيانات.

أُضيف في الإصدارة 237.

StubDevicePartUUID، StubImageIdentifier

مشابه لـ LoaderDevicePartUUID و LoaderImageIdentifier، لكنه يشير إلى موقع ثنائي EFI لصورة النواة الموحدة بدلاً من موقع ثنائي محمل الإقلاع، بغض النظر عن الإقلاع عبر محمل إقلاع أم لا.

أُضيف في الإصدار 257.

StubInfo

معلومات موجزة عن الكعب. استخدم bootctl(1) لعرض هذه البيانات.

أُضيف في الإصدار 250.

StubPcrKernelImage

فهرس سجل PCR الذي تُقاس فيه صورة النواة، صورة initrd، شاشة الإقلاع، قاعدة بيانات شجرة الجهاز، وسطر الأوامر المضمن، مُنسَّق كسلسلة ASCII عشرية (مثال "11"). يُضبَط هذا المتغير إذا أُكمل القياس بنجاح، ويبقى غير مضبوط بخلاف ذلك.

أُضيف في الإصدار 252.

StubPcrKernelParameters

فهرس سجل PCR الذي يُقاس فيه سطر أوامر النواة وبيانات الاعتماد، مُنسَّق كسلسلة ASCII عشرية (مثال "12"). يُضبَط هذا المتغير إذا أُكمل القياس بنجاح، ويبقى غير مضبوط بخلاف ذلك.

أُضيف في الإصدار 252.

StubPcrInitRDSysExts

فهرس سجل PCR لإضافات النظام لـ initrd، التي تُلتقط من نظام الملفات الذي توجد عليه صورة النواة. مُنسَّق كسلسلة ASCII عشرية (مثال "13"). يُضبَط هذا المتغير إذا أُكمل القياس بنجاح، ويبقى غير مضبوط بخلاف ذلك.

أُضيف في الإصدار 252.

StubPcrInitRDConfExts

فهرس سجل PCR لإضافات التهيئة لـ initrd، التي تُلتقط من نظام الملفات الذي توجد عليه صورة النواة. مُنسَّق كسلسلة ASCII عشرية (مثال "12"). يُضبَط هذا المتغير إذا أُكمل القياس بنجاح، ويبقى غير مضبوط بخلاف ذلك.

أُضيف في الإصدار 255.

StubProfile

الفهرس الرقمي للملف الشخصي المُحدَّد، بدون "@"، مُنسَّق كسلسلة عشرية. يُضبَط على كل من UKIs أحادية الملف الشخصي ومتعددة الملفات الشخصية. (في الحالة الأولى، يُضبَط هذا المتغير إلى "0" دون شرط.)

أُضيف في الإصدار 257.

لاحظ أن بعض المتغيرات أعلاه قد تُضبَط أيضًا بواسطة محمل الإقلاع. سيضبطها الكعب فقط إذا لم تكن مضبوطة بالفعل. بعض هذه المتغيرات مُعرَّفة بواسطة Boot Loader Interface[5].

موارد INITRD¶

تُمرَّر الموارد التالية كأرشيفات cpio initrd إلى النواة المُقلعة، وبالتالي تُشكِّل التسلسل الهرمي الأولي لنظام الملفات في بيئة تنفيذ initrd:

/

initrd الرئيسي من مقطع PE ".initrd" لصورة النواة الموحدة.

أُضيف في الإصدار 252.

/.extra/credentials/*.cred

تُنسخ ملفات الاستيثاق (اللاحقة ".cred") الموضوعة بجوار صورة النواة الموحدة (كما هو موصوف أعلاه) إلى الدليل /.extra/credentials/ في بيئة تنفيذ initrd.

أُضيف في الإصدار 252.

/.extra/global_credentials/*.cred

وبالمثل، تُنسخ ملفات الاستيثاق في الدليل /loader/credentials/ في نظام الملفات الذي توضع فيه صورة النواة الموحدة إلى الدليل /.extra/global_credentials/ في بيئة تنفيذ initrd.

أُضيف في الإصدار 252.

/.extra/sysext/*.sysext.raw

تُنسخ ملفات صور إضافة النظام (اللاحقة ".sysext.raw") الموضوعة بجوار صورة النواة الموحدة (كما هو موصوف أعلاه) إلى الدليل /.extra/sysext/ في بيئة تنفيذ initrd.

أُضيف في الإصدار 252.

/.extra/confext/*.confext.raw

تُنسخ ملفات صور إضافة التهيئة (اللاحقة ".confext.raw") الموضوعة بجوار صورة النواة الموحدة (كما هو موصوف أعلاه) إلى الدليل /.extra/confext/ في بيئة تنفيذ initrd.

أُضيف في الإصدار 255.

/.extra/tpm2-pcr-signature.json

يُنسخ كائن JSON لتوقيع TPM2 PCR المضمن في مقطع PE ".pcrsig" لصورة النواة الموحدة إلى الملف /.extra/tpm2-pcr-signature.json في بيئة تنفيذ initrd.

أُضيف في الإصدار 252.

/.extra/tpm2-pcr-public-key.pem

يُنسخ المفتاح العام PEM المضمن في مقطع PE ".pcrpkey" لصورة النواة الموحدة إلى الملف /.extra/tpm2-pcr-public-key.pem في بيئة تنفيذ initrd.

أُضيف في الإصدار 252.

/\&.extra/profile، /\&.extra/os-release

محتويات مقطعي ".profile" و".osrel" للملف الشخصي المُختار، إن وُجد.

أُضيف في الإصدار 257.

لاحظ أن جميع هذه الملفات موجودة في نظام الملفات "tmpfs" الذي تُعدّه النواة للتسلسل الهرمي لملفات initrd، وبالتالي تُفقد عند انتقال النظام من بيئة تنفيذ initrd إلى نظام الملفات المضيف. إذا كان من المقرر الاحتفاظ بهذه الموارد خلال هذا الانتقال، فيجب نسخها أولاً إلى مكان يبقى بعد الانتقال، مثلاً عبر سطر tmpfiles.d(5) مناسب. مبدئيًا، يُفعل ذلك لملفات توقيع TPM2 PCR والمفتاح العام.

سلاسل SMBIOS من النوع 11¶

يمكن تهيئة systemd-stub باستخدام سلاسل SMBIOS من النوع 11. تتكون السلاسل القابلة للتطبيق من اسم، متبوع بـ "="، متبوع بالقيمة. ما لم يكتشف systemd-stub أنه يعمل داخل بيئة حوسبة سرية، سيبحث systemd-stub في الجدول عن سلسلة ذات اسم محدد، وإذا وُجدت، سيستخدم قيمتها. تُقرأ السلاسل التالية:

io.systemd.stub.kernel-cmdline-extra

إذا ضُبطت، تُضاف قيمة هذه السلسلة إلى قائمة وسائط سطر أوامر النواة التي تُقاس في PCR12 وتُمرَّر إلى النواة.

أُضيف في الإصدار 254.

تجميع صور النواة¶

لتجميع صورة نواة موحدة قابلة للإقلاع من مكونات مختلفة كما هو موصوف أعلاه، استخدم ukify(1).

انظر أيضًا¶

systemd-boot(7), systemd.exec(5), systemd-creds(1), systemd-sysext(8), مواصفات محمل الإقلاع[6], واجهة محمل الإقلاع[5], ukify(1), systemd-measure(1), قياسات TPM2 PCR التي أجراها systemd[7]