الاسم¶

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

ESP/loader/extensions/*.raw

ESP/loader/extensions/*.sysext.raw

ESP/loader/extensions/*.confext.raw

الوصف¶

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 دائمًا أول قسم مطابق. تُجرى المطابقة بأخذ أول سلسلة "متوافقة" من DeviceTree المقدمة من البرامج الثابتة في جداول التهيئة ومقارنتها بأول سلسلة "متوافقة" من كل قسم ".dtbauto". إذا لم توفر البرامج الثابتة DeviceTree، تُجرى المطابقة باستخدام قسم ".hwids" بدلاً من ذلك. بعد اختيار قسم ".hwids" (انظر الوصف أدناه)، تُستخدم سلسلة "المتوافقة" من ذلك القسم لتنفيذ نفس إجراء المطابقة. إذا وُجد تطابق، يُحمّل ذلك القسم ".dtbauto" وسيتجاوز ".dtb" إذا كان موجودًا.

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

•صفر أو أكثر من أقسام ".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، انظر مواصفات UAPI.5 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. يُفترض استخدام هذا لتمرير صور إضافية لامتداد النظام خاصة بـ UKI إلى initrd. انظر systemd-sysext(8) للحصول على تفاصيل حول صور امتداد النظام. يتم قياس أرشيف cpio المُنشأ الذي يحتوي على صور امتداد النظام هذه في TPM PCR 13 (إذا كان TPM موجودًا).

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

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

•بالمثل، يتم تعبئة الملفات /loader/extensions/*.confext.raw في أرشيف cpio ووضعها في دليل /.extra/global_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 الموقعة.

لاحظ أن المكونات السابقة لعملية الإقلاع قد تسجل أنظمة initrd إضافية، وبالتالي موارد "رفيقة" إضافية مثل إضافات النظام وإضافات التهيئة وبيانات الاعتماد لاستهلاك النواة ونظام التشغيل الذي يُقلع في النهاية. على سبيل المثال، systemd-boot(7) يفعل ذلك للموارد المهيأة في سطور UAPI.1 من النوع #1 "الإضافية". سيجمع systemd-stub أي موارد موفرة بهذه الطريقة مع موارد الملفات الرفيقة التي يكتسبها بنفسه.

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='Factory Reset this Device'").

ملاحظات 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.

LoaderTpm2ActivePcrBanks

تمثيل سلسلة سداسي عشري لقناع بتات بقيم محددة في مواصفات بروتوكول TCG EFI لـ TPM 2.0 مثل EFI_TCG2_BOOT_HASH_ALG_*. إذا لم يُكتشف دعم TPM2 أو لم توجد بنوك نشطة، سيُضبط على 0. يضبطه محمل الإقلاع. استخدم systemd-analyze(1) لعرض هذه البيانات.

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

LoaderImageIdentifier

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

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

StubDevicePartUUID، StubImageIdentifier

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

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

StubDeviceURL

إذا استُدعيت صورة النواة عبر الإقلاع الشبكي، يحتوي هذا المتغير على عنوان URL الأصلي. قد يُستخدم هذا للحصول آلياً على موارد إضافية من نفس المصدر.

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

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.

LoaderPcrSMBIOS

تُقاس هياكل SMBIOS المحددة بمؤشر سجل PCR في النوع 1 (معلومات النظام، مع حقل "نوع الاستيقاظ" المتغير المُصفّر)، والنوع 2 (معلومات اللوحة الأساسية) والنوع 11 (سلاسل OEM). مُنسقة كسلسلة ASCII عشرية (مثل "1"). يُضبط هذا المتغير إذا أُكمل القياس بنجاح، ويبقى غير مضبوط بخلاف ذلك. يُجري systemd-stub هذا القياس فقط إذا لم يُنجز بالفعل في نفس الإقلاع (مثلًا بواسطة محمل الإقلاع)، كما يُشار إليه بكون هذا المتغير مضبوطًا مسبقًا.

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

LoaderBootSecret

متغير EFI غير متطاير لا يُمكن الوصول إليه إلا من بيئة ما قبل الإقلاع (أي الوصول من نظام التشغيل غير مسموح) يحتوي على سر خاص بكل نظام. يُضبط آليًا بواسطة systemd-stub إذا لم يكن موجودًا مسبقًا. يُمرر سر مشتق من قيمة متغير EFI هذا إلى نظام التشغيل في /.extra/boot-secret، انظر أدناه.

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

لاحظ أن بعض المتغيرات أعلاه قد تُضبَط أيضًا بواسطة محمل الإقلاع. سيضبطها الكعب فقط إذا لم تكن مضبوطة بالفعل. بعض هذه المتغيرات مُعرَّفة بواسطة 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/global_sysext/*.sysext.raw

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

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

/.extra/confext/*.confext.raw

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

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

/.extra/global_confext/*.confext.raw

وبالمثل، تُنسخ ملفات صور إضافة التهيئة (اللاحقة ".confext.raw") الموضوعة في الدليل /loader/extensions/ في نظام الملفات الذي توضع فيه صورة النواة الموحدة إلى الدليل /.extra/global_confext/ في بيئة تنفيذ initrd.

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

/.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.

/.extra/boot-secret

سر خاص بكل نظام بحجم 32 بايت مشتق من سر بحجم 32 بايت مخزن في متغير EFI (LoaderBootSecret، انظر أعلاه)، والذي لا يمكن الوصول إليه إلا من بيئة ما قبل الإقلاع. قد يُستخدم لأغراض تشفيرية متنوعة في مرحلة الإقلاع المبكرة، ويُقتصر وصول نظام الملفات إليه على الجذر. تُدمج بيانات IMAGE_ID=/ID= من ملف ".osrel" في السر عبر التجزئة، لضمان تمرير سر مميز لصور مختلفة. علاوة على ذلك، تُدمج قيمة عشوائية بحجم 32 بايت مخزنة في ESP في ملف "/loader/boot-secret-mixin" عبر التجزئة أيضًا، مما يضمن أن الأقراص المختلفة تؤدي إلى أسرار إقلاع مختلفة.

ملاحظة: سر الإقلاع هذا محمي في النهاية فقط بواسطة ضوابط الوصول المفروضة من البرامج الثابتة على متغير EFI. هذه حماية أضعف بكثير بشكل عام من الأساليب القائمة على TPM، ولذا يُوصى بشدة باستخدام TPM على الأنظمة التي تمتلك واحدًا. يُقصد من سر الإقلاع أساسًا أن يكون حلاً بديلاً بأمان أقل للحالات التي لا يتوفر فيها TPM.

يجب ألا تحمي التطبيقات الموارد مباشرة بهذا السر، بل تستمد سرها الخاص منه (بتجزئته مع بعض معرفات التطبيق، في وضع HMAC على سبيل المثال)، وذلك لتجنب تسريب سر الإقلاع الرئيسي عن طريق الخطأ.

لاحظ أن سر الإقلاع متاح فقط إذا كانت بيئة ما قبل الإقلاع تمتلك مصدر RNG مناسب في الإقلاع الحالي أو إقلاع سابق. يمكن أن يكون هذا المصدر بذرة عشوائية مهيأة على القرص أو دعم EFI RNG، أو كليهما.

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

لاحظ أن جميع هذه الملفات موجودة في نظام الملفات "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.

io.systemd.boot.loglevel

إذا ضُبطت، فستُستخدم قيمة هذه السلسلة كمستوى للسجل. القيم الصالحة (من الأكثر إلى الأقل خطورة) هي "emerg" و "alert" و "crit" و "err" و "warning" و "notice" و "info" و "debug".

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

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

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

انظر أيضًا¶

systemd-boot(7)، systemd.exec(5)، systemd-creds(1)، systemd-sysext(8)، UAPI.1 Boot Loader Specification[6]، Boot Loader Interface[5]، ukify(1)، systemd-measure(1)، TPM2 PCR Measurements Made by systemd[7]