'\" t .TH "UKIFY" "1" "" "systemd 261.3" "ukify" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .\" http://bugs.debian.org/507673 .\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .ie \n(.g .ds Aq \(aq .el .ds Aq ' .\" ----------------------------------------------------------------- .\" * set default formatting .\" ----------------------------------------------------------------- .\" disable hyphenation .nh .\" disable justification (adjust text to left margin only) .ad l .\" ----------------------------------------------------------------- .\" * MAIN CONTENT STARTS HERE * .\" ----------------------------------------------------------------- .SH "نام (NAME)" ukify \- ترکیب و ساخت تصاویر هسته یکپارچه (Unified Kernel Images - UKI) .SH "خلاصه دستور (SYNOPSIS)" .HP \w'\fBukify\fR\ 'u \fBukify\fR [OPTIONS...] build .HP \w'\fBukify\fR\ 'u \fBukify\fR [OPTIONS...] genkey .HP \w'\fBukify\fR\ 'u \fBukify\fR [OPTIONS...] inspect FILE... .SH "توضیحات (DESCRIPTION)" .PP \fBukify\fR ابزاری است که هدف اصلی آن ترکیب اجزا (معمولاً یک هسته، یک initrd و استاب UEFI \fBsystemd-stub\fR(7)) برای ایجاد یک \m[blue]\fBتصویر هسته یکپارچه UAPI\&.5 (به انگلیسی: UKI)\fR\m[]\&\s-2\u[1]\d\s+2 است \(em یک فایل باینری PE منفرد که سیستم را بوت می‌کند\&. هنگامی که UKI اجرا می‌شود، استاب، هسته لینوکس جاسازی‌شده را استخراج کرده و بوت می‌کند\&. این UKI می‌تواند مستقیماً توسط سفت‌افزار یا از طریق یک بارگذار بوت راه‌اندازی شود\&. هنگام استفاده با \m[blue]\fBqemu\fR\m[]\&\s-2\u[2]\d\s+2، یک UKI همچنین می‌تواند از طریق «بوت مستقیم هسته» اجرا شود؛ مثال زیر را ببینید\&. .PP \fBukify\fR همچنین می‌تواند برای تولید انواع دیگر تصاویر شبیه UKI، به‌ویژه افزونه‌ها استفاده شود\&. توضیحات دستور \fBbuild\fR در زیر را ببینید\&. \fBukify\fR همچنین می‌تواند گواهی‌ها و کلیدهایی برای SecureBoot و امضای PCR تولید کند؛ توضیحات دستور \fBgenkey\fR در زیر را ببینید\&. \fBukify\fR همچنین می‌تواند اطلاعات دقیقی درباره تصاویر هسته یکپارچه چاپ کند؛ توضیحات دستور \fBinspect\fR در زیر را ببینید\&. .SH "دستورات (COMMANDS)" .PP دستورات زیر پشتیبانی می‌شوند: .SS "build" .PP این دستور یک تصویر هسته یکپارچه ایجاد می‌کند\&. دو گزینه اصلی که باید برای دستور \fBbuild\fR مشخص شوند عبارتند از \fILinux=\fR/\fB\-\-linux=\fR و \fIInitrd=\fR/\fB\-\-initrd=\fR\&. \fIInitrd=\fR چندین مسیر جداشده با فاصله را می‌پذیرد و \fB\-\-initrd=\fR می‌تواند چندین بار مشخص شود\&. .PP بخش‌های اضافی، یا به‌صورت خودکار یا تنها در صورت ارائه گزینه‌ای خاص، در UKI درج خواهند شد\&. توضیحات مربوط به \fIMicrocode=\fR/\fB\-\-microcode=\fR، \fICmdline=\fR/\fB\-\-cmdline=\fR، \fIOSRelease=\fR/\fB\-\-os\-release=\fR، \fIDeviceTree=\fR/\fB\-\-devicetree=\fR، \fIDeviceTreeAuto=\fR/\fB\-\-devicetree\-auto=\fR، \fIHWIDs=\fR/\fB\-\-hwids=\fR، \fISplash=\fR/\fB\-\-splash=\fR، \fIPCRPKey=\fR/\fB\-\-pcrpkey=\fR، \fIUname=\fR/\fB\-\-uname=\fR، \fISBAT=\fR/\fB\-\-sbat=\fR و \fB\-\-section=\fR در زیر را ببینید\&. .PP \fBukify\fR همچنین می‌تواند برای سرهم‌بندی یک باینری PE استفاده شود که قابل اجرا نیست اما حاوی داده‌های کمکی است، برای مثال مدخل‌های اضافی خط فرمان هسته\&. .PP اگر کلیدهای امضای PCR از طریق گزینه‌های \fIPCRPrivateKey=\fR/\fB\-\-pcr\-private\-key=\fR و \fIPCRPublicKey=\fR/\fB\-\-pcr\-public\-key=\fR یا \fIPCRCertificate=\fR/\fB\-\-pcr\-certificate=\fR ارائه شوند، مقادیر PCR که پس از بوت شدن با هسته، initrd و سایر بخش‌های داده‌شده مشاهده خواهند شد، محاسبه، امضا و در UKI جاسازی می‌شوند\&. \fBsystemd-measure\fR(1) برای انجام این محاسبه و امضا استفاده می‌شود\&. .PP محاسبه مقادیر PCR برای مسیرهای خاص فاز بوت انجام می‌شود\&. این مسیرها را می‌توان با گزینه \fIPhases=\fR/\fB\-\-phases=\fR مشخص کرد\&. در صورت عدم تعیین، مقدار پیش‌فرض ارائه‌شده توسط \fBsystemd\-measure\fR استفاده می‌شود\&. همچنین می‌توان آرگومان‌های \fIPCRPrivateKey=\fR/\fB\-\-pcr\-private\-key=\fR، \fIPCRPublicKey=\fR/\fB\-\-pcr\-public\-key=\fR یا \fIPCRCertificate=\fR/\fB\-\-pcr\-certificate=\fR، و \fIPhases=\fR/\fB\-\-phases=\fR را بیش از یک بار مشخص کرد\&. در این صورت، امضاها با هر یک از کلیدهای مشخص‌شده انجام می‌شوند\&. در خط فرمان، هنگامی که هر دو گزینه \fB\-\-phases=\fR و \fB\-\-pcr\-private\-key=\fR استفاده می‌شوند، باید به تعداد یکسان مشخص شوند، و سپس مجموعه مسیر فاز بوت n\-ام با کلید n\-ام امضا خواهد شد\&. این قابلیت را می‌توان برای ساخت خط‌مشی‌های اعتماد متفاوت برای فازهای مختلف بوت استفاده کرد\&. در فایل پیکربندی، \fIPCRPrivateKey=\fR، \fIPCRPublicKey=\fR و \fIPhases=\fR در بخش‌های جداگانه‌ای گروه‌بندی می‌شوند که فازهای بوت مجزا را توصیف می‌کنند\&. اگر یکی از گزینه‌های \fISigningEngine=\fR/\fB\-\-signing\-engine=\fR یا \fISigningProvider=\fR/\fB\-\-signing\-provider=\fR مشخص شود، آرگومان‌های کلید خصوصی عیناً به عنوان URI به \fBopenssl\fR(1) ارسال می‌شوند، و آرگومان‌های کلید عمومی به عنوان گواهی‌های X\&.509 بارگذاری خواهند شد، تا امضا بتواند به ترتیب با یک موتور یا ارائه‌دهنده OpenSSL انجام شود\&. .PP اگر یک کلید امضای SecureBoot از طریق گزینه \fISecureBootPrivateKey=\fR/\fB\-\-secureboot\-private\-key=\fR ارائه شود، باینری PE حاصل به‌طور کلی امضا خواهد شد، که به UKI حاصل امکان می‌دهد توسط SecureBoot مورد اعتماد قرار گیرد\&. همچنین بحث ثبت خودکار در \fBsystemd-boot\fR(7) را ببینید\&. .PP اگر استاب و/یا هسته حاوی بخش‌های "\&.sbat" باشند، آن‌ها در UKI ادغام خواهند شد تا به‌روزرسانی‌های ابطال که بر هر یک تأثیر می‌گذارند، هنگام بارگذاری UKI توسط Shim در نظر گرفته شوند\&. برای اطلاعات بیشتر در مورد SBAT به \m[blue]\fBمستندات Shim\fR\m[]\&\s-2\u[3]\d\s+2 مراجعه کنید\&. .SS "genkey" .PP این دستور کلیدها را برای امضای PCR و کلید و گواهی مورداستفاده برای امضای SecureBoot ایجاد می‌کند\&. همان گزینه‌های پیکربندی که تعیین می‌کنند چه کلیدهایی و در چه مسیرهایی برای امضا هنگام استفاده از \fBbuild\fR مورد نیاز خواهند بود، در اینجا تعیین می‌کنند که چه کلیدهایی ایجاد شوند\&. توضیحات مربوط به \fIPCRPrivateKey=\fR/\fB\-\-pcr\-private\-key=\fR، \fIPCRPublicKey=\fR/\fB\-\-pcr\-public\-key=\fR و \fISecureBootPrivateKey=\fR/\fB\-\-secureboot\-private\-key=\fR در زیر را ببینید\&. .PP فایل‌های خروجی نباید از قبل وجود داشته باشند\&. .SS "inspect" .PP نمایش اطلاعات درباره بخش‌های موجود در یک یا چند باینری داده‌شده\&. اگر \fB\-\-all\fR داده شود، تمام بخش‌ها نشان داده می‌شوند\&. در غیر این صورت، اگر گزینه \fB\-\-section=\fR حداقل یک بار مشخص شده باشد، تنها همان بخش‌ها نشان داده می‌شوند\&. در غیر این صورت، بخش‌های شناخته‌شده‌ای که معمولاً در یک UKI گنجانده می‌شوند نشان داده خواهند شد\&. برای هر بخش، نام، اندازه و خلاصه sha256 آن چاپ می‌شود\&. برای بخش‌های متنی، محتویات چاپ می‌شود\&. .PP همچنین توضیحات مربوط به \fB\-j\fR/\fB\-\-json=\fR و \fB\-\-section=\fR را ببینید\&. .PP سایر ابزارهایی که ممکن است برای بازرسی UKIها مفید باشند: \fBllvm-objdump\fR(1) \fB\-p\fR و \fBpe\-inspect\fR\&. .SH "گزینه‌ها (OPTIONS)" .PP تنظیمات می‌توانند در فایل‌های پیکربندی (با نحو \fISomeSetting=\fR\fI\fIvalue\fR\fR) و در خط فرمان (با نحو \fB\-\-some\-setting=\fR\fB\fIvalue\fR\fR) ظاهر شوند\&. برای برخی پارامترهای خط فرمان، یک میانبر تک‌حرفی نیز مجاز است\&. در فایل‌های پیکربندی، تنظیمات باید در بخش مناسب قرار گیرند، از این رو توضیحات در زیر بر اساس بخش‌ها گروه‌بندی شده‌اند\&. هنگامی که یک تنظیم یکسان هم در فایل پیکربندی و هم در خط فرمان ظاهر می‌شود، به‌طور کلی تنظیم خط فرمان اولویت بالاتری دارد و تنظیم فایل پیکربندی را کاملاً بازنویسی می‌کند\&. اگر تنظیمی رفتار متفاوتی داشته باشد، در ادامه شرح داده شده است\&. .PP اگر هیچ فایل پیکربندی از طریق گزینه \fB\-\-config=\fR\fB\fIPATH\fR\fR ارائه نشود، \fBukify\fR تلاش خواهد کرد تا یک فایل پیکربندی پیش‌فرض را به این ترتیب در مسیرهای زیر جستجو کند: /etc/systemd/ukify\&.conf، /run/systemd/ukify\&.conf، /usr/local/lib/systemd/ukify\&.conf، و /usr/lib/systemd/ukify\&.conf، و سپس اولین موردی را که پیدا شد بارگذاری می‌کند\&. اگر هیچ فایل پیکربندی مشخص نشده باشد و هیچ فایل پیش‌فرضی نیز پیدا نشود، \fBukify\fR به کار عادی خود ادامه خواهد داد\&. .PP آرگومان‌های مکانی \fILINUX\fR و \fIINITRD\fR، یا تنظیمات معادل \fILinux=\fR و \fIInitrd=\fR، اختیاری هستند\&. اگر بیش از یک initrd مشخص شود، همگی در یک بخش PE واحد ترکیب خواهند شد\&. این امر برای مثال جهت الحاق ریزکد (microcode) قبل از initrd اصلی مفید است\&. .PP گزینه‌ها و تنظیمات زیر پشتیبانی می‌شوند: .SS "Command line\-only options" .PP \fB\-\-config=\fR\fB\fIPATH\fR\fR .RS 4 پیکربندی را از فایل پیکربندی داده‌شده بارگذاری می‌کند\&. به‌طور کلی، تنظیمات مشخص‌شده در فایل پیکربندی اولویت کمتری نسبت به تنظیمات مشخص‌شده از طریق گزینه‌ها دارند\&. مواردی که گزینه خط فرمان به‌طور کامل تنظیم فایل پیکربندی را بازنویسی نمی‌کند، در توضیحات هر گزینه به‌صراحت ذکر شده است\&. .sp در نسخه ۲۵۴ اضافه شد\&. .RE .PP \fB\-\-measure\fR, \fB\-\-no\-measure\fR .RS 4 فعال یا غیرفعال کردن فراخوانی \fBsystemd-measure\fR(1) برای چاپ مقادیر از پیش محاسبه‌شده PCR\&. به‌طور پیش‌فرض false است\&. .sp در نسخه ۲۵۳ اضافه شد\&. .RE .PP \fB\-\-policy\-digest\fR, \fB\-\-no\-policy\-digest\fR .RS 4 فعال یا غیرفعال کردن فراخوانی \fBsystemd-measure\fR(1) برای چاپ خلاصه‌های خط‌مشی TPM2 از پیش محاسبه‌شده\&. برای امضای آفلاین خط‌مشی‌های PCR مفید است\&. به‌طور پیش‌فرض false است\&. .sp در نسخه ۲۵۸ اضافه شد\&. .RE .PP \fB\-\-section=\fR\fB\fINAME\fR\fR\fB:\fR\fB\fITEXT\fR\fR\fB|\fR\fB\fI@PATH\fR\fR, \fB\-\-section=\fR\fB\fINAME\fR\fR\fB:text|binary\fR\fB[@\fIPATH\fR]\fR .RS 4 برای تمام دستورات به جز \fBinspect\fR، نحو اول استفاده می‌شود\&. یک بخش دلخواه اضافی "\fINAME\fR" را مشخص می‌کند\&. آرگومان می‌تواند یک رشته متنی صریح یا "@" به همراه نام یک مسیر باشد\&. این گزینه می‌تواند بیش از یک بار مشخص شود\&. هر بخشی که به این روش مشخص شود (به ترتیب) قبل از بخش "\&.linux" که همیشه آخرین بخش است درج خواهد شد\&. .sp برای دستور \fBinspect\fR، نحو دوم استفاده می‌شود\&. بخش \fINAME\fR بازرسی خواهد شد (در صورت یافت شدن)\&. اگر آرگومان دوم "text" باشد، محتویات چاپ خواهد شد\&. اگر آرگومان سوم داده شود، محتویات در فایلی با نام \fIPATH\fR ذخیره خواهد شد\&. .sp توجه داشته باشید که نام همان‌گونه که هست استفاده می‌شود، و اگر نام بخش باید با نقطه شروع شود، باید در \fINAME\fR گنجانده شود\&. .sp در نسخه ۲۵۳ اضافه شد\&. .RE .PP \fB\-\-join\-profile=\fR\fB\fIPATH\fR\fR .RS 4 مسیری را به یک فایل PE موجود حاوی یک پروفایل اضافی دریافت می‌کند تا به تصویر هسته یکپارچه اضافه شود\&. پروفایل را می‌توان از قبل با \fBukify\fR تولید کرد\&. نیازی نیست که پروفایل امضا شده باشد یا حاوی اندازه‌گیری‌های PCR باشد\&. تمام بخش‌های PE مربوط به UKI فایل PE مشخص‌شده در UKI تولیدشده کپی می‌شوند\&. این گزینه برای تولید UKIهای چند پروفایله مفید است\&. توجه داشته باشید که این کار فقط بخش‌های PE تعریف‌شده توسط مشخصات UKI را کپی می‌کند، و بخش‌های دیگر، مانند "\&.text" یا موارد مشابه را نادیده می‌گیرد\&. .sp در نسخه ۲۵۷ اضافه شد\&. .RE .PP \fB\-\-sign\-profile=\fR\fB\fIID\fR\fR .RS 4 شناسه پروفایلی را دریافت می‌کند که باید برای آن اندازه‌گیری‌های امضاشده PCR توسط ukify تولید شود\&. این گزینه را می‌توان همراه با \fB\-\-join\-profile=\fR هنگام ساخت تصویر نهایی هسته یکپارچه استفاده کرد\&. اگر مشخص نشود، اندازه‌گیری‌های امضاشده PCR برای تمام پروفایل‌ها اضافه خواهد شد\&. .sp در نسخه ۲۵۸ اضافه شد\&. .RE .PP \fB\-\-join\-pcrsig=\fR\fB\fIPATH\fR\fR, \fB\-\-pcrsig=\fR\fB\fITEXT\fR\fR\fB|\fR\fB\fI@PATH\fR\fR .RS 4 گزینه \fB\-\-join\-pcrsig=\fR مسیری را به یک فایل PE موجود حاوی یک UKI از پیش ساخته‌شده دریافت می‌کند\&. \fB\-\-pcrsig=\fR مسیری را به یک حباب JSON مربوط به pcrsig موجود، یا یک حباب درون‌خطی عین کلمه دریافت می‌کند\&. آن‌ها باید با هم و بدون تعیین هیچ پارامتر بخش UKI دیگری استفاده شوند\&. \fBukify\fR حباب JSON مربوط به pcrsig را به UKI پیوست خواهد کرد\&. این گزینه در ترکیب با \fB\-\-policy\-digest\fR برای ایجاد یک UKI و سپس امضای آفلاین خلاصه‌های خط‌مشی TPM2 مفید است\&. .sp در نسخه ۲۵۸ اضافه شد\&. .RE .PP \fB\-\-tools=\fR\fB\fIDIRS\fR\fR .RS 4 یک یا چند دایرکتوری حاوی ابزارهای کمکی را مشخص می‌کند\&. \fBukify\fR ابتدا ابزارهای کمکی را در آن دایرکتوری‌ها جستجو می‌کند، و اگر پیدا نشدند، تلاش می‌کند تا آن‌ها را طبق معمول از \fI$PATH\fR بارگذاری کند\&. .sp در نسخه ۲۵۳ اضافه شد\&. .RE .PP \fB\-\-output=\fR\fB\fIFILENAME\fR\fR .RS 4 نام فایل خروجی\&. اگر مشخص نشود، نام آرگومان \fILINUX\fR، با پسوند "\&.unsigned\&.efi" یا "\&.signed\&.efi" بسته به این که آیا امضا برای SecureBoot انجام شده است یا خیر، استفاده خواهد شد\&. .sp در نسخه ۲۵۳ اضافه شد\&. .RE .PP \fB\-\-summary\fR .RS 4 خلاصه‌ای از پیکربندی بارگذاری‌شده را چاپ کرده و خارج می‌شود\&. این گزینه برای بررسی نحوه ترکیب گزینه‌های فایل پیکربندی و خط فرمان مفید است\&. .sp در نسخه ۲۵۴ اضافه شد\&. .RE .PP \fB\-\-all\fR .RS 4 چاپ تمام بخش‌ها (با دستور \fBinspect\fR)\&. .sp در نسخه ۲۵۵ اضافه شد\&. .RE .PP \fB\-\-json\fR .RS 4 تولید خروجی JSON (با دستور \fBinspect\fR)\&. خروجی یک شیء است که کلیدهای آن نام‌های بخش‌های مشترک بین تمام پروفایل‌ها هستند (یعنی بخش‌های قبل از اولین بخش "\&.profile")، که هر کدام به شیئی نگاشت می‌شوند که بخش را بر اساس "size" و "sha256" آن، به اضافه یک فیلد "text" برای بخش‌های متنی توصیف می‌کند\&. بخش‌های UKI که می‌توانند چندین بار (در همان پروفایل) ظاهر شوند به صورت آرایه نشان داده می‌شوند\&. اگر تصویر حاوی پروفایل‌ها باشد، یک کلید اضافی "_profiles" حاوی آرایه‌ای با یک شیء به ازای هر پروفایل است که هر کدام به همین ترتیب با نام بخش کلیدگذاری شده‌اند (شروع با بخش "\&.profile" آن)\&. .sp در نسخه ۲۵۵ اضافه شد\&. .RE .PP \fB\-h\fR, \fB\-\-help\fR .RS 4 یک متن راهنمای کوتاه را چاپ کرده و خارج می‌شود\&. .RE .PP \fB\-\-version\fR .RS 4 یک رشته نسخه کوتاه را چاپ کرده و خارج می‌شود\&. .RE .SS "[UKI] section" .PP \fILinux=\fR\fI\fILINUX\fR\fR, \fB\-\-linux=\fR\fB\fILINUX\fR\fR .RS 4 مسیری به فایل باینری هسته\&. .sp در نسخه ۲۵۴ اضافه شد\&. .RE .PP \fIOSRelease=\fR\fI\fITEXT\fR\fR\fI|\fR\fI\fI@PATH\fR\fR, \fB\-\-os\-release=\fR\fB\fITEXT\fR\fR\fB|\fR\fB\fI@PATH\fR\fR .RS 4 توصیف os\-release (بخش "\&.osrel")\&. آرگومان می‌تواند یک رشته متنی صریح یا "@" به همراه نام یک مسیر باشد\&. اگر مشخص نشود، فایل \fBos-release\fR(5) از سیستم میزبان برداشته خواهد شد\&. اگر صراحتاً روی یک رشته خالی تنظیم شود، بخش "\&.osrel" از UKI حذف می‌شود (این کار در اغلب موارد توصیه نمی‌شود و باعث می‌شود که خروجی حاصل توسط ابزارهای دیگر مانند \fBkernel\-install\fR و \fBbootctl\fR به عنوان یک UKI شناخته نشود)\&. .sp در نسخه ۲۵۳ اضافه شد\&. .RE .PP \fICmdline=\fR\fI\fITEXT\fR\fR\fI|\fR\fI\fI@PATH\fR\fR, \fB\-\-cmdline=\fR\fB\fITEXT\fR\fR\fB|\fR\fB\fI@PATH\fR\fR .RS 4 خط فرمان هسته (بخش "\&.cmdline")\&. آرگومان می‌تواند یک رشته متنی صریح یا "@" به همراه نام یک مسیر باشد\&. اگر مشخص نشود، هیچ خط فرمانی جاسازی نخواهد شد\&. .sp در نسخه ۲۵۳ اضافه شد\&. .RE .PP \fIInitrd=\fR\fI\fIINITRD\fR\fR\fI\&.\&.\&.\fR, \fB\-\-initrd=\fR\fB\fILINUX\fR\fR .RS 4 صفر یا چند مسیر initrd\&. در فایل پیکربندی، موارد با فاصله از هم جدا می‌شوند\&. initrdها به ترتیبِ مشخص‌شدن ترکیب می‌شوند، به‌طوری که initrdهای مشخص‌شده در فایل پیکربندی در ابتدا قرار می‌گیرند\&. .sp در نسخه ۲۵۴ اضافه شد\&. .RE .PP \fIMicrocode=\fR\fI\fIUCODE\fR\fR, \fB\-\-microcode=\fR\fB\fIUCODE\fR\fR .RS 4 مسیر به initrd حاوی به‌روزرسانی‌های ریزکد (microcode)\&. اگر مشخص نشود، این بخش وجود نخواهد داشت\&. .sp در نسخه ۲۵۶ اضافه شد\&. .RE .PP \fISplash=\fR\fI\fIPATH\fR\fR, \fB\-\-splash=\fR\fB\fIPATH\fR\fR .RS 4 تصویری برای نمایش در طول بوت (بخش "\&.splash")\&. آرگومان، مسیری به یک فایل BMP است\&. اگر مشخص نشود، این بخش وجود نخواهد داشت\&. .sp در نسخه ۲۵۳ اضافه شد\&. .RE .PP \fIDeviceTree=\fR\fI\fIPATH\fR\fR, \fB\-\-devicetree=\fR\fB\fIPATH\fR\fR .RS 4 توصیف devicetree (بخش "\&.dtb")\&. آرگومان، مسیری به یک فایل کامپایل‌شده دودویی DeviceTree است\&. اگر مشخص نشود، این بخش وجود نخواهد داشت\&. .sp در نسخه ۲۵۳ اضافه شد\&. .RE .PP \fIDeviceTreeAuto=\fR\fI\fIPATH\fR\fR\fI\&.\&.\&.\fR, \fB\-\-devicetree\-auto=\fR\fB\fIPATH\fR\fR .RS 4 صفر یا چند فایل DeviceTree با قابلیت انتخاب خودکار\&. در فایل پیکربندی، موارد با فاصله از هم جدا می‌شوند\&. هر DeviceTree در یک بخش "\&.dtbauto" جداگانه قرار خواهد گرفت\&. .sp در نسخه ۲۵۷ اضافه شد\&. .RE .PP \fIHWIDs=\fR\fI\fIPATH\fR\fR, \fB\-\-hwids=\fR\fB\fIPATH\fR\fR .RS 4 جدول شناسه سخت‌افزاری دستگاه (بخش "\&.hwids")\&. آرگومان، مسیری به یک دایرکتوری حاوی فایل‌های توصیف دستگاه JSON HWID است\&. هر فایل باید شامل یک شیء JSON واحد با کلیدهای "name"، "compatible" و "hwids" باشد\&. کلیدهای "name" و "compatible" باید مقادیر رشته‌ای داشته باشند و کلید "hwids" باید لیستی از رشته‌ها به عنوان مقدار داشته باشد، که در آن رشته‌ها باید UUIDهای معتبری باشند که بیانگر CHID/HWID هستند\&. مثال: .sp .if n \{\ .RS 4 .\} .nf { "type": "devicetree", "name": "Example Laptop 16 Gen 7", "compatible": "example,laptop\-16\-g7", "hwids": [ "5dc05bf4\-01f6\-4089\-b464\-a08c47ea9295", "3e3f8f3c\-2003\-46f2\-811c\-85554f7d5952" ] } .fi .if n \{\ .RE .\} .sp در اینجا "Example Laptop 16 Gen 7" نام دستگاه "name" (طبق تعریف سازنده) است، "example,laptop\-16\-g7" مقدار "compatible" (طبق تعریف هسته) است و "hwids" آرایه‌ای از CHIDها/HWIDها است (برای مثال استخراج‌شده از خروجی \fBfwupdtool hwids\fR)\&. اگر مشخص نشود، و دایرکتوری "/usr/lib/systemd/boot/hwids/[EFI_ARCH]/" وجود داشته باشد، آنگاه این بخش به‌طور خودکار از آن دایرکتوری پر خواهد شد (یک رشته خالی را به عنوان پارامتر این گزینه مشخص کنید تا این رفتار غیرفعال شود)، در غیر این صورت وجود نخواهد داشت\&. توصیه می‌شود در صورتی که قرار است از DeviceTreeهای با قابلیت انتخاب خودکار استفاده شود، این پارامتر مشخص گردد\&. .sp در نسخه ۲۵۷ اضافه شد\&. .RE .PP \fIUname=\fR\fI\fIVERSION\fR\fR, \fB\-\-uname=\fR\fB\fIVERSION\fR\fR .RS 4 مشخص کردن نسخه هسته (همانند \fBuname \-r\fR، بخش "\&.uname")\&. اگر مشخص نشود، تلاشی برای استخراج رشته نسخه از تصویر هسته صورت خواهد گرفت\&. توصیه می‌شود در صورت آگاهی، این مقدار صراحتاً ارسال شود، زیرا استخراج بر پایه روش‌های اکتشافی است و چندان قابل اعتماد نیست\&. اگر مشخص نشود و استخراج با شکست مواجه شود، این بخش وجود نخواهد داشت\&. .sp در نسخه ۲۵۳ اضافه شد\&. .RE .PP \fISBAT=\fR\fI\fITEXT\fR\fR\fI|\fR\fI\fI@PATH\fR\fR, \fB\-\-sbat=\fR\fB\fITEXT\fR\fR\fB|\fR\fB\fI@PATH\fR\fR .RS 4 متاداده SBAT مرتبط با UKI یا افزونه\&. خط‌مشی‌های SBAT برای ابطال کل گروه‌های UKIها یا افزونه‌ها با یک به‌روزرسانی خط‌مشی ایستا که فضایی را در DBX/MOKX اشغال نمی‌کند، مفید هستند\&. اگر به‌صورت دستی مشخص نشود، یک مدخل متاداده پیش‌فرض متشکل از .sp .if n \{\ .RS 4 .\} .nf uki,1,UKI,uki,1,https://uapi\-group\&.org/specifications/specs/unified_kernel_image .fi .if n \{\ .RE .\} .sp برای UKIها و .sp .if n \{\ .RS 4 .\} .nf uki\-addon,1,UKI Addon,addon,1,https://www\&.freedesktop\&.org/software/systemd/man/latest/systemd\-stub\&.html .fi .if n \{\ .RE .\} .sp برای افزونه‌ها استفاده خواهد شد، تا اطمینان حاصل شود که ابطال آن‌ها همواره امکان‌پذیر است\&. برای اطلاعات بیشتر در مورد SBAT به \m[blue]\fBمستندات Shim\fR\m[]\&\s-2\u[3]\d\s+2 مراجعه کنید\&. .sp در نسخه ۲۵۴ اضافه شد\&. .RE .PP \fIPCRPKey=\fR\fI\fIPATH\fR\fR, \fB\-\-pcrpkey=\fR\fB\fIPATH\fR\fR .RS 4 مسیری به یک کلید عمومی برای جاسازی در بخش "\&.pcrpkey"\&. اگر مشخص نشود، و دقیقاً یک آرگومان \fIPCRPublicKey=\fR/\fB\-\-pcr\-public\-key=\fR یا \fIPCRCertificate=\fR/\fB\-\-pcr\-certificate=\fR وجود داشته باشد، از آن کلید استفاده خواهد شد\&. در غیر این صورت، این بخش وجود نخواهد داشت\&. .sp در نسخه ۲۵۳ اضافه شد\&. .RE .PP \fIProfile=\fR\fI\fIPATH\fR\fR, \fB\-\-profile=\fR\fB\fIPATH\fR\fR .RS 4 مسیری به یک پروفایل UKI برای قرار دادن در یک بخش "\&.profile"\&. این گزینه برای ایجاد UKIهای چند پروفایله مفید است، و معمولاً در ترکیب با \fB\-\-join\-profile=\fR استفاده می‌شود تا UKI مشخص‌شده با یک پروفایل اضافی گسترش یابد\&. .sp در نسخه ۲۵۷ اضافه شد\&. .RE .PP \fIPCRBanks=\fR\fI\fIPATH\fR\fR, \fB\-\-pcr\-banks=\fR\fB\fIPATH\fR\fR .RS 4 فهرستی از بانک‌های PCR جداشده با کاما یا فاصله برای امضای یک خط‌مشی\&. در صورت عدم وجود، تمام بانک‌های شناخته‌شده استفاده خواهند شد ("sha1"، "sha256"، "sha384"، "sha512")، که در صورت عدم پشتیبانی توسط سیستم با شکست مواجه خواهد شد\&. .sp در نسخه ۲۵۳ اضافه شد\&. .RE .PP \fISecureBootSigningTool=\fR\fI\fISIGNER\fR\fR, \fB\-\-signtool=\fR\fB\fISIGNER\fR\fR .RS 4 اینکه از "sbsign"، "pesign" یا "systemd\-sbsign" استفاده شود\&. بسته به این انتخاب، پارامترهای متفاوتی برای امضای یک تصویر مورد نیاز است\&. پیش‌فرض "sbsign" است\&. .sp در نسخه ۲۵۴ اضافه شد\&. .RE .PP \fISecureBootPrivateKey=\fR\fI\fISB_KEY\fR\fR, \fB\-\-secureboot\-private\-key=\fR\fB\fISB_KEY\fR\fR .RS 4 مسیری به یک کلید خصوصی برای استفاده جهت امضای باینری حاصل\&. اگر گزینه \fISigningEngine=\fR/\fB\-\-signing\-engine=\fR یا \fISigningProvider=\fR/\fB\-\-signing\-provider=\fR استفاده شود، این ممکن است یک نام‌گذاری ویژه موتور یا ارائه‌دهنده نیز باشد\&. این گزینه توسط \fISecureBootSigningTool=sbsign\fR/\fB\-\-signtool=sbsign\fR و \fISecureBootSigningTool=systemd\-sbsign\fR/\fB\-\-signtool=systemd\-sbsign\fR الزامی است\&. .sp در نسخه ۲۵۳ اضافه شد\&. .RE .PP \fISecureBootCertificate=\fR\fI\fISB_CERT\fR\fR, \fB\-\-secureboot\-certificate=\fR\fB\fISB_CERT\fR\fR .RS 4 مسیری به یک گواهی برای استفاده جهت امضای باینری حاصل\&. اگر گزینه \fISigningEngine=\fR/\fB\-\-signing\-engine=\fR یا \fISigningProvider=\fR/\fB\-\-signing\-provider=\fR استفاده شود، این ممکن است یک نام‌گذاری ویژه موتور یا ارائه‌دهنده نیز باشد\&. این گزینه توسط \fISecureBootSigningTool=sbsign\fR/\fB\-\-signtool=sbsign\fR و \fISecureBootSigningTool=systemd\-sbsign\fR/\fB\-\-signtool=systemd\-sbsign\fR الزامی است\&. .sp در نسخه ۲۵۳ اضافه شد\&. .RE .PP \fISecureBootCertificateDir=\fR\fI\fISB_PATH\fR\fR, \fB\-\-secureboot\-certificate\-dir=\fR\fB\fISB_PATH\fR\fR .RS 4 مسیری به یک دایرکتوری پایگاه‌داده گواهی nss برای استفاده جهت امضای باینری حاصل\&. هنگامی که \fISecureBootSigningTool=pesign\fR/\fB\-\-signtool=pesign\fR استفاده می‌شود تأثیر می‌گذارد\&. پیش‌فرض /etc/pki/pesign است\&. .sp در نسخه ۲۵۴ اضافه شد\&. .RE .PP \fISecureBootCertificateName=\fR\fI\fISB_CERTNAME\fR\fR, \fB\-\-secureboot\-certificate\-name=\fR\fB\fISB_CERTNAME\fR\fR .RS 4 نام مدخل پایگاه‌داده گواهی nss برای استفاده جهت امضای باینری حاصل\&. این گزینه توسط \fISecureBootSigningTool=pesign\fR/\fB\-\-signtool=pesign\fR الزامی است\&. .sp در نسخه ۲۵۴ اضافه شد\&. .RE .PP \fISecureBootCertificateValidity=\fR\fI\fIDAYS\fR\fR, \fB\-\-secureboot\-certificate\-validity=\fR\fB\fIDAYS\fR\fR .RS 4 مدت اعتبار (به روز) برای یک گواهی ایجادشده توسط \fBgenkey\fR\&. پیش‌فرض ۳۶۵۰، یعنی ۱۰ سال است\&. .sp در نسخه ۲۵۴ اضافه شد\&. .RE .PP \fISigningEngine=\fR\fI\fIENGINE\fR\fR, \fB\-\-signing\-engine=\fR\fB\fIENGINE\fR\fR .RS 4 یک موتور OpenSSL برای استفاده جهت امضای باینری حاصل و اندازه‌گیری‌های PCR؛ به \fBopenssl-engine\fR(1) مراجعه کنید\&. .sp در نسخه ۲۵۳ اضافه شد\&. .RE .PP \fISigningProvider=\fR\fI\fIPROVIDER\fR\fR, \fB\-\-signing\-provider=\fR\fB\fIPROVIDER\fR\fR .RS 4 یک ارائه‌دهنده OpenSSL برای استفاده جهت امضای باینری حاصل و اندازه‌گیری‌های PCR؛ به \fBprovider\fR(7) مراجعه کنید\&. این گزینه فقط زمانی می‌تواند استفاده شود که \fBsystemd\-sbsign\fR به عنوان ابزار امضا استفاده شود\&. .sp در نسخه ۲۵۷ اضافه شد\&. .RE .PP \fICertificateProvider=\fR\fI\fIPROVIDER\fR\fR, \fB\-\-certificate\-provider=\fR\fB\fIPROVIDER\fR\fR .RS 4 یک ارائه‌دهنده OpenSSL برای استفاده جهت بارگذاری گواهی مورد استفاده برای امضای باینری حاصل و اندازه‌گیری‌های PCR؛ به \fBprovider\fR(7) مراجعه کنید\&. این گزینه فقط زمانی می‌تواند استفاده شود که \fBsystemd\-sbsign\fR به عنوان ابزار امضا استفاده شود\&. .sp در نسخه ۲۵۷ اضافه شد\&. .RE .PP \fISignKernel=\fR\fI\fIBOOL\fR\fR, \fB\-\-sign\-kernel\fR, \fB\-\-no\-sign\-kernel\fR .RS 4 نادیده گرفتن تشخیص خودکار این که آیا خود باینری لینوکس قبل از جاسازی در تصویر ترکیبی امضا شود یا خیر\&. اگر مشخص نشود، در صورتی که یک کلید امضای SecureBoot از طریق گزینه \fISecureBootPrivateKey=\fR/\fB\-\-secureboot\-private\-key=\fR ارائه شود و باینری قبلاً امضا نشده باشد، امضا خواهد شد\&. اگر \fISignKernel=\fR/\fB\-\-sign\-kernel\fR روی true باشد، و باینری قبلاً امضا شده باشد، امضا در هر حال ضمیمه خواهد شد\&. .sp در نسخه ۲۵۳ اضافه شد\&. .RE .SS "[PCRSignature:\fINAME\fR] section" .PP در فایل پیکربندی، این گزینه‌ها بر اساس بخش گروه‌بندی می‌شوند\&. در خط فرمان، آن‌ها باید به همان ترتیب مشخص شوند\&. بخش‌های مشخص‌شده در هر دو منبع ترکیب می‌شوند\&. .PP \fIPCRPrivateKey=\fR\fI\fIPATH\fR\fR, \fB\-\-pcr\-private\-key=\fR\fB\fIPATH\fR\fR .RS 4 یک کلید خصوصی برای استفاده جهت امضای خط‌مشی‌های PCR\&. در خط فرمان، این گزینه ممکن است بیش از یک بار مشخص شود، که در این صورت امضاهای متعددی ایجاد خواهد شد\&. .sp در نسخه ۲۵۳ اضافه شد\&. .RE .PP \fIPCRPublicKey=\fR\fI\fIPATH\fR\fR, \fB\-\-pcr\-public\-key=\fR\fB\fIPATH\fR\fR .RS 4 یک کلید عمومی برای استفاده جهت امضای خط‌مشی‌های PCR\&. .sp در خط فرمان، این گزینه ممکن است بیش از یک بار مشخص شود، مشابه با گزینه \fB\-\-pcr\-private\-key=\fR\&. اگر وجود نداشته باشد، کلیدهای عمومی از کلیدهای خصوصی استخراج خواهند شد\&. در خط فرمان، در صورت وجود، این گزینه باید به تعداد یکسان با گزینه \fB\-\-pcr\-private\-key=\fR مشخص شود\&. در صورت استفاده از \fB\-\-pcr\-certificate=\fR نمی‌تواند مشخص شود\&. .sp در نسخه ۲۵۳ اضافه شد\&. .RE .PP \fIPCRCertificate=\fR\fI\fIPATH\fR\fR, \fB\-\-pcr\-certificate=\fR\fB\fIPATH\fR\fR .RS 4 یک گواهی X\&.509 برای استفاده جهت امضای خط‌مشی‌های PCR\&. .sp در خط فرمان، این گزینه ممکن است بیش از یک بار مشخص شود، مشابه با گزینه \fB\-\-pcr\-private\-key=\fR\&. اگر وجود نداشته باشد، کلیدهای عمومی از کلیدهای خصوصی استخراج خواهند شد\&. در خط فرمان، در صورت وجود، این گزینه باید به تعداد یکسان با گزینه \fB\-\-pcr\-private\-key=\fR مشخص شود\&. در صورت استفاده از \fB\-\-pcr\-public\-key=\fR نمی‌تواند مشخص شود\&. .sp در نسخه ۲۵۸ اضافه شد\&. .RE .PP \fIPhases=\fR\fI\fILIST\fR\fR, \fB\-\-phases=\fR\fB\fILIST\fR\fR .RS 4 فهرستی از مسیرهای فاز جداشده با دو نقطه، تفکیک‌شده با کاما یا فاصله برای امضای خط‌مشی\&. هر مجموعه از مسیرهای فاز بوت با کلید خصوصی متناظر امضا خواهد شد\&. در صورت عدم وجود، مقدار پیش‌فرض \fBsystemd-measure\fR(1) استفاده خواهد شد\&. .sp در خط فرمان، هنگامی که این آرگومان وجود دارد، باید به تعداد یکسان با گزینه \fB\-\-pcr\-private\-key=\fR ظاهر شود\&. .sp در نسخه ۲۵۳ اضافه شد\&. .RE .SH "مثال‌ها (EXAMPLES)" .PP \fBمثال\ \&۱.\ \&فراخوانی کمینه\fR .sp .if n \{\ .RS 4 .\} .nf $ ukify build \e \-\-linux=/lib/modules/6\&.0\&.9\-300\&.fc37\&.x86_64/vmlinuz \e \-\-initrd=/some/path/initramfs\-6\&.0\&.9\-300\&.fc37\&.x86_64\&.img \e \-\-cmdline=\*(Aqquiet rw\*(Aq .fi .if n \{\ .RE .\} .PP این دستور یک UKI امضانشده به نام \&./vmlinuz\&.unsigned\&.efi ایجاد می‌کند\&. .PP \fBمثال\ \&۲.\ \&بوت مستقیم هسته در یک ماشین مجازی\fR .PP هنگام استفاده از \m[blue]\fBqemu\fR\m[]\&\s-2\u[2]\d\s+2 با \m[blue]\fBOVMF\fR\m[]\&\s-2\u[4]\d\s+2 (سفت‌افزار UEFI برای ماشین‌های مجازی) می‌توان از سوییچ \fB\-kernel\fR مستقیماً همراه با یک UKI استفاده کرد\&. مثال: .PP \fBqemu\-kvm \-drive if=pflash,format=qcow2,readonly=on,file=/usr/share/edk2/ovmf/OVMF_CODE_4M\&.qcow2 \-kernel \fR\fB\&./vmlinuz\&.unsigned\&.efi\fR\fB \fR\fB\fI[ \&.\&.\&. ]\fR\fR\fB \fR .PP (مسیر فایل سفت‌افزار ممکن است بسته به توزیع نیاز به تنظیم داشته باشد\&.) معمولاً یک آرگومان دیگر \fB\-drive\fR برای اتصال یک ایمیج دیسک واقعی استفاده می‌شود، اما این کار اجباری نیست\&. .PP \fBمثال\ \&۳.\ \&تمامی ویژگی‌ها و امکانات\fR .sp .if n \{\ .RS 4 .\} .nf $ ukify build \e \-\-linux=/lib/modules/6\&.0\&.9\-300\&.fc37\&.x86_64/vmlinuz \e \-\-initrd=early_cpio \e \-\-initrd=/some/path/initramfs\-6\&.0\&.9\-300\&.fc37\&.x86_64\&.img \e \-\-sbat=\*(Aqsbat,1,SBAT Version,sbat,1,https://github\&.com/rhboot/shim/blob/main/SBAT\&.md uki\&.author\&.myimage,1,UKI for System,uki\&.author\&.myimage,1,https://uapi\-group\&.org/specifications/specs/unified_kernel_image\*(Aq \e \-\-pcr\-private\-key=tpm2\-pcr\-initrd\-private\-key\&.pem \e \-\-pcr\-public\-key=tpm2\-pcr\-initrd\-public\-key\&.pem \e \-\-phases=\*(Aqenter\-initrd\*(Aq \e \-\-pcr\-private\-key=tpm2\-pcr\-private\-key\-system\&.pem \e \-\-pcr\-public\-key=tpm2\-pcr\-public\-key\-system\&.pem \e \-\-phases=\*(Aqenter\-initrd:leave\-initrd enter\-initrd:leave\-initrd:sysinit \e enter\-initrd:leave\-initrd:sysinit:ready\*(Aq \e \-\-pcr\-banks=sha384,sha512 \e \-\-secureboot\-private\-key=secureboot\-private\-key\&.pem \e \-\-secureboot\-certificate=secureboot\-certificate\&.pem \e \-\-sign\-kernel \e \-\-cmdline=\*(Aqquiet rw rhgb\*(Aq .fi .if n \{\ .RE .\} .PP این دستور یک UKI امضاشده به نام \&./vmlinuz\&.signed\&.efi ایجاد می‌کند\&. بخش initrd شامل دو بخش به هم پیوسته است: early_cpio و initramfs\-6\&.0\&.9\-300\&.fc37\&.x86_64\&.img\&. خط‌مشی جاسازی‌شده در بخش "\&.pcrsig" برای initrd (فاز \fBenter\-initrd\fR) با کلید tpm2\-pcr\-initrd\-private\-key\&.pem، و برای سیستم اصلی (فازهای \fBleave\-initrd\fR، \fBsysinit\fR، \fBready\fR) با کلید tpm2\-pcr\-private\-key\-system\&.pem امضا خواهد شد\&. باینری لینوکس و تصویر ترکیبی حاصل با کلید SecureBoot به نام secureboot\-private\-key\&.pem امضا خواهند شد\&. .PP \fBمثال\ \&۴.\ \&تمامی ویژگی‌ها و امکانات از طریق یک فایل پیکربندی\fR .PP این همان مثال قبلی است، اما این بار پیکربندی در یک فایل ذخیره شده است: .sp .if n \{\ .RS 4 .\} .nf $ cat ukify\&.conf [UKI] Initrd=early_cpio Cmdline=quiet rw rhgb SecureBootPrivateKey=secureboot\-private\-key\&.pem SecureBootCertificate=secureboot\-certificate\&.pem SignKernel=yes PCRBanks=sha384,sha512 [PCRSignature:initrd] PCRPrivateKey=tpm2\-pcr\-initrd\-private\-key\&.pem PCRPublicKey=tpm2\-pcr\-initrd\-public\-key\&.pem Phases=enter\-initrd [PCRSignature:system] PCRPrivateKey=tpm2\-pcr\-private\-key\-system\&.pem PCRPublicKey=tpm2\-pcr\-public\-key\-system\&.pem Phases=enter\-initrd:leave\-initrd enter\-initrd:leave\-initrd:sysinit enter\-initrd:leave\-initrd:sysinit:ready $ ukify \-c ukify\&.conf build \e \-\-linux=/lib/modules/6\&.0\&.9\-300\&.fc37\&.x86_64/vmlinuz \e \-\-initrd=/some/path/initramfs\-6\&.0\&.9\-300\&.fc37\&.x86_64\&.img .fi .if n \{\ .RE .\} .PP یک "initrd" (با نام early_cpio) در فایل پیکربندی مشخص شده است، و initrd دیگر (با نام initramfs\-6\&.0\&.9\-300\&.fc37\&.x86_64\&.img) در خط فرمان مشخص شده است\&. این امر برای مثال زمانی مفید است که اولین initrd حاوی ریزکد (microcode) برای پردازنده باشد و برخلاف initrd واقعی، با تغییر نسخه هسته نیازی به به‌روزرسانی نداشته باشد\&. .PP \fBمثال\ \&۵.\ \&افزونه PE خط فرمان هسته\fR .sp .if n \{\ .RS 4 .\} .nf ukify build \e \-\-secureboot\-private\-key=secureboot\-private\-key\&.pem \e \-\-secureboot\-certificate=secureboot\-certificate\&.pem \e \-\-cmdline=\*(Aqdebug\*(Aq \e \-\-sbat=\*(Aqsbat,1,SBAT Version,sbat,1,https://github\&.com/rhboot/shim/blob/main/SBAT\&.md uki\-addon\&.author,1,UKI Addon for System,uki\-addon\&.author,1,https://www\&.freedesktop\&.org/software/systemd/man/systemd\-stub\&.html\*(Aq \-\-output=debug\&.addon\&.efi .fi .if n \{\ .RE .\} .PP این دستور یک باینری PE امضاشده ایجاد می‌کند که حاوی پارامتر خط فرمان اضافی هسته یعنی "debug" همراه با متاداده SBAT ارجاع‌دهنده به مالک افزونه است\&. .PP \fBمثال\ \&۶.\ \&تصمیم‌گیری درباره خط‌مشی امضا، و ایجاد گواهی و کلیدها\fR .PP ابتدا، بیایید یک فایل پیکربندی ایجاد کنیم که مشخص می‌کند چه امضاهایی باید انجام شوند: .sp .if n \{\ .RS 4 .\} .nf # cat >/etc/kernel/uki\&.conf <base\&.pcrs .fi .if n \{\ .RE .\} .PP سپس، خلاصه‌های PCR را به‌صورت آفلاین امضا کرده و در حباب JSON درج کنید: .sp .if n \{\ .RS 4 .\} .nf #!/usr/bin/python3 import base64, json, subprocess priv_key = \*(Aq/home/zbyszek/src/systemd/tpm2\-pcr\-private\&.pem\*(Aq base_file = \*(Aqbase\&.pcrs\*(Aq base = json\&.load(open(base_file)) for bank,policies in base\&.items(): for policy in policies: pol = base64\&.b16decode(policy[\*(Aqpol\*(Aq]\&.upper()) call = subprocess\&.run([\*(Aqopenssl\*(Aq, \*(Aqdgst\*(Aq, f\*(Aq\-{bank}\*(Aq, \*(Aq\-sign\*(Aq, priv_key], input=pol, check=True, capture_output=True) sig = base64\&.b64encode(call\&.stdout)\&.decode() policy[\*(Aqsig\*(Aq] = sig print(json\&.dumps(base)) .fi .if n \{\ .RE .\} .PP در نهایت، حباب به‌روزشده JSON را به UKI پیوست کنید: .sp .if n \{\ .RS 4 .\} .nf $ ukify build \e \-\-join\-pcrsig=base\&.efi \e \-\-pcrsig=@base\&.pcrs \e \-\-json=short \e \-\-output=base\-signed\&.efi .fi .if n \{\ .RE .\} .PP تصویر UKI حاصل به نام base\-signed\&.efi اکنون شامل خلاصه‌های امضاشده PCR خواهد بود\&. .SH "همچنین ببینید (SEE ALSO)" .PP \fBsystemd\fR(1), \fBsystemd-stub\fR(7), \fBsystemd-boot\fR(7), \fBsystemd-measure\fR(1), \fBsystemd-pcrphase.service\fR(8) .SH "نکات (NOTES)" .IP " 1." 4 UAPI.5 Unified Kernel Image (UKI) .RS 4 \%https://uapi-group.org/specifications/specs/unified_kernel_image .RE .IP " 2." 4 qemu .RS 4 \%https://www.qemu.org/docs/master .RE .IP " 3." 4 Shim documentation .RS 4 \%https://github.com/rhboot/shim/blob/main/SBAT.md .RE .IP " 4." 4 OVMF .RS 4 \%https://www.linux-kvm.org/downloads/lersek/ovmf-whitepaper-c770f8c.txt .RE