نام (NAME)

iucode_tool - ابزار مدیریت و بارگذاری ریزکد پردازنده‌های اینتل

خلاصه دستور (SYNOPSIS)

iucode_tool [options] [[-ttype] filename|dirname] ...

توضیحات (DESCRIPTION)

iucode_tool ابزاری است که می‌تواند داده‌های ریزکد پردازنده‌های Intel® را از فایل‌هایی با قالب‌های متنی و باینری بسته‌های ریزکد بارگذاری کند.

این ابزار می‌تواند فهرستی از ریزکدهای موجود در این فایل‌ها را در خروجی نمایش دهد، آن‌ها را ادغام کند، برای ارتقای ریزکد در هسته‌های پردازنده سیستم در هسته بارگذاری نماید، یا برخی از آن‌ها را برای استفاده‌های بعدی در قالب باینری درون یک فایل بنویسد.

iucode_tool تمام ریزکدهای موجود در فایل‌ها و دایرکتوری‌های مشخص‌شده را جهت پردازش در حافظه بارگذاری می‌کند. ریزکدهای تکراری و قدیمی نادیده گرفته خواهند شد. این ابزار همچنین می‌تواند با مشخص کردن نام فایل به‌صورت “-” (علامت منفی)، داده‌های ریزکد را از ورودی استاندارد (stdin) بخواند.

فایل‌های داده ریزکد چنانچه پسوند dat. داشته باشند، در قالب متنی dat. فرض می‌شوند و در غیر این صورت باینری در نظر گرفته خواهند شد. ورودی استاندارد (stdin) به‌صورت پیش‌فرض در قالب متنی dat. فرض می‌شود. با استفاده از گزینه -t می‌توان نوع فایل‌های مشخص‌شده پس از آن (از جمله برای stdin) را تغییر داد.

اگر یک دایرکتوری مشخص شود، تمام فایل‌هایی که نام آن‌ها با نقطه آغاز نمی‌شود، بدون ترتیب مشخصی بارگذاری خواهند شد. از دایرکتوری‌های تو در تو صرف‌نظر می‌شود.

فایل‌ها و دایرکتوری‌های خالی نادیده گرفته شده و از آن‌ها رد خواهد شد.

می‌توانید با استفاده از گزینه‌های -S، -s، --date-before و --date-after مشخص کنید که کدام ریزکدها باید در خروجی نوشته، فهرست یا در هسته بارگذاری شوند. چنانچه هیچ‌یک از این گزینه‌ها مشخص نشوند، تمامی ریزکدها انتخاب خواهند شد.

می‌توانید ریزکدهای انتخاب‌شده را در هسته بارگذاری کنید، آن‌ها را در یک فایل (با قالب باینری)، در یک بایگانی early initramfs لینوکس، در فایل‌های مجزا برای هر امضای پردازنده در یک دایرکتوری، یا در فایل‌های مجزا برای هر ریزکد در یک دایرکتوری بنویسید؛ این کار با استفاده از گزینه‌های -w، --write-earlyfw، -k، -K و -W انجام می‌شود.

iucode_tool ریزکدها را در پیام‌های خروجی و خطای خود با نماد “n/k” مشخص می‌کند، که در آن “n” شماره بسته و “k” شماره ریزکد درون آن بسته است. خروجی گزینه --list-all هنگام پردازش چندین فایل ورودی، بهترین نمونه از نحوه کارکرد این نماد است.

برای اطلاعات بیشتر درباره ریزکدهای پردازنده‌های اینتل، لطفاً مستندات ارائه‌شده و راهنماهای اینتل ذکرشده در بخش همچنین ببینید (SEE ALSO) را مطالعه فرمایید.

گزینه‌ها (OPTIONS)

iucode_tool گزینه‌های زیر را می‌پذیرد:

-q, --quiet: جلوگیری از خروجی‌های معمول برنامه (حالت بی‌صدا).
-v, --verbose: چاپ اطلاعات بیشتر. برای افزایش سطح جزئیات، می‌توان بیش از یک بار از آن استفاده کرد.
-h, -?, --help: نمایش تمام گزینه‌های موجود و معانی آن‌ها.
--usage: نمایش خلاصه‌ای از گزینه‌ها و نحوه استفاده.
-V, --version: نمایش نسخه برنامه.
-t type: تعیین نوع فایل برای فایل‌های بعدی. مقدار type می‌تواند یکی از موارد زیر باشد:

b: قالب باینری. این همان قالبی است که توسط درایور هسته و BIOS/EFI استفاده می‌شود و در بخش 9.11 از راهنمای Intel 64 and IA‐32 Architectures Software Developer's Manual, Volume 3A به‌تفصیل توضیح داده شده است.
d: قالب متنی dat. ریزکد اینتل. این قالبی است که معمولاً توسط شرکت اینتل برای توزیع فایل‌های داده ریزکد به کار می‌رود.
r: بازیابی ریزکد در قالب باینری. فایل‌های باینری فشرده‌نشده عمومی را برای یافتن و بازیابی ریزکدهایی در قالب باینری اینتل جستجو می‌کند. توجه: ممکن است ریزکدهایی پیدا شوند که بررسی‌های سخت‌گیرانه را پاس نکنند و در نتیجه اگر گزینه‌های --no-strict-checks یا --ignore-broken فعال نباشند، باعث خروج iucode_tool شوند.
a: (پیش‌فرض) iucode_tool از پسوند نام فایل برای تعیین نوع فایل استفاده می‌کند: قالب متنی dat. برای فایل‌هایی که پسوند .dat دارند و نوع باینری برای سایر فایل‌ها. توجه داشته باشید که برای stdin، قالب متنی dat. فرض می‌شود.

--downgrade: هنگامی که چندین نسخه از ریزکد یک پردازنده خاص از فایل‌های مختلف در دسترس باشد، نسخه‌ای از فایلی که در آخر بارگذاری شده نگه‌داری می‌شود، صرف‌نظر از سطح ویرایش (revision). فایل‌ها همیشه به همان ترتیبی که در خط فرمان مشخص شده‌اند بارگذاری می‌شوند. این گزینه زمانی که فقط یک فایل بارگذاری شده باشد هیچ تاثیری ندارد.
--no-downgrade: هنگامی که چندین نسخه از ریزکد یک پردازنده خاص از فایل‌های مختلف در دسترس باشد، نسخه‌ای با بالاترین سطح ویرایش (revision) نگه‌داری می‌شود. این حالت، شیوه عملکرد پیش‌فرض است.
--strict-checks: انجام بررسی‌های سخت‌گیرانه روی داده‌های ریزکد. از بارگذاری ریزکدها و فایل‌های داده ریزکد با اندازه و متادیتای غیرمنتظره خودداری می‌کند. همچنین از بارگذاری ورودی‌های ریزکدی که متادیتای یکسان ولی محتوای (payload) متفاوتی دارند جلوگیری خواهد کرد. این حالت، شیوه عملکرد پیش‌فرض است.
--no-strict-checks: انجام بررسی‌های با سخت‌گیری کمتر روی داده‌های ریزکد. فقط در صورتی استفاده شود که با یک فایل داده ریزکد مواجه شده‌اید که حاوی ریزکدهایی با اندازه‌های نامتعارف یا متادیتای نادرستِ غیربحرانی (مانند تاریخ‌های نامعتبر) است و می‌خواهید آن‌ها را حفظ کنید. اگر تنها می‌خواهید از این موارد رد شوید، از گزینه --ignore-broken استفاده کنید.
--ignore-broken: صرف‌نظر کردن از ورودی‌های معیوب ریزکد هنگام بارگذاری یک فایل داده ریزکد، به جای توقف اجرای برنامه. اگر ورودی ریزکد قالبی پشتیبانی‌نشده داشته باشد یا هدر آن به‌شدت آسیب دیده باشد، باید از تمام داده‌های باقی‌مانده در فایل صرف‌نظر شود. در این حالت، استفاده از نوع فایلِ بازیابی ریزکد در قالب باینری (گزینه -tr) توصیه می‌شود، زیرا می‌تواند از روی داده‌های ریزکد به‌شدت آسیب‌دیده رد شود.
--no-ignore-broken: در صورت مشاهده ریزکد معیوب هنگام بارگذاری فایل داده ریزکد، اجرای برنامه را متوقف می‌کند. این حالت، شیوه عملکرد پیش‌فرض است.
-s ! | [!]signature[,[pf_mask][,[lt:|eq:|gt:]revision]]: ریزکدها را بر اساس signature (امضا)، pf_mask (ماسک فلگ‌های پردازنده) و revision (نسخه ویرایش) مشخص‌شده انتخاب می‌کند.

اگر pf_mask مشخص شده باشد، تنها ریزکدهایی انتخاب می‌شوند که دست‌کم با یکی از ترکیب‌های فلگ پردازنده موجود در ماسک سازگار باشند.

اگر revision مشخص شده باشد، و اختیاری با یکی از عملگرهای “eq:”، “lt:” یا “gt:” پیشوند شده باشد، فقط ریزکدهایی را انتخاب می‌کند که ویرایش یکسانی داشته باشند (در صورت عدم استفاده از عملگر، یا در صورت استفاده از عملگر “eq:”)، یا ریزکدهایی که ویرایش آن‌ها کمتر از (عملگر “lt:”) یا بیشتر از (عملگر “gt:”) مقدار مشخص‌شده باشد.

برای انتخاب ریزکدهای بیشتر، این گزینه را می‌توان چندین بار مشخص کرد. این گزینه را می‌توان با گزینه --scan-system ترکیب کرد تا ریزکدهای بیشتری انتخاب شوند. اگر به ابتدای signature یک علامت “!” (علامت تعجب) اضافه شود، به جای انتخاب، ریزکدها را از انتخاب خارج می‌کند. ترتیب گزینه‌ها مهم است؛ گزینه‌های -s بعدی، موارد قبلی از جمله --scan-system را لغو و بازنویسی می‌کنند.

هنگام مشخص کردن signature و pf_mask، اعداد هگزادسیمال باید با پیشوند “0x” و اعداد هشت‌هشتی (octal) با “0” مشخص شوند. اعداد ده‌دهی (decimal) نباید صفر ابتدایی داشته باشند، در غیر این صورت به عنوان عدد هشت‌هشتی تفسیر خواهند شد.

نماد ویژه -s! (بدون پارامتر signature) به iucode_tool دستور می‌دهد که نیاز به گنجاندن صریح امضاهای ریزکد داشته باشد (با استفاده از شکل بدون نفی -s یا با استفاده از --scan-system).

-S, --scan-system[=mode]: انتخاب ریزکدها از طریق پویش پردازنده‌های فعال (online) این سیستم برای یافتن امضای آن‌ها.

از این گزینه تنها یک بار می‌توان استفاده کرد، و می‌توان آن را با گزینه -s ترکیب کرد تا ریزکدهای بیشتری انتخاب شوند. ریزکدهای انتخاب‌شده با --scan-system را می‌توان با گزینه بعدی -s !signature از حالت انتخاب خارج کرد.

آرگومان اختیاری mode (که تنها در نگارش طولانی گزینه پذیرفته می‌شود) روش پویش پردازنده‌ها را تعیین می‌کند:

0 یا auto: در حال حاضر معادل fast است، اما در نسخه‌های آینده در صورتی که اینتل سیستم‌هایی با چند امضا فراتر از mixed-stepping به کار گیرد، ممکن است تغییر کند. این حالت برای حفظ سازگاری با نسخه‌های پیشین iucode_tool، حالت پیش‌فرض عملکرد است.
1 یا fast: از دستور cpuid برای تشخیص امضای پردازنده‌ای که iucode_tool روی آن در حال اجراست استفاده می‌کند و تمامی steppingهای نوع، خانواده و مدل آن پردازنده را انتخاب می‌نماید. از سیستم‌های mixed-stepping پشتیبانی می‌کند.
2 یا exact: از درایورهای هسته برای پویش مستقیم امضای هر یک از پردازنده‌های فعال سیستم استفاده می‌کند. این حالت از سیستم‌های چندامضایی پشتیبانی می‌کند. این روش پویش در سیستم‌های بزرگ با تعداد پردازنده‌های زیاد کند خواهد بود و احتمالاً به مجوزهای ویژه (مانند اجرا با دسترسی کاربر ریشه / root) نیاز دارد. در صورتی که پویش به هر دلیلی با شکست مواجه شود، به عنوان یک اقدام ایمنی (fail-safe)، یک هشدار صادر می‌کند و تمام steppingهای ممکن را برای هر امضایی که با موفقیت پویش کرده در نظر می‌گیرد.

--date-before=YYYY-MM-DD و --date-after=YYYY-MM-DD: محدود کردن ریزکدهای انتخاب‌شده بر اساس یک بازه تاریخی. تاریخ باید در قالب استاندارد ISO با چهار رقم برای سال، دو رقم برای ماه و دو رقم برای روز داده شود و از “-” (علامت منفی) به عنوان جداکننده استفاده شود. محدوده تاریخ‌ها اعتبارسنجی نمی‌شود، بنابراین می‌توانید از --date-after=2000-00-00 برای انتخاب تمام ریزکدهای پس از ۱ ژانویه ۲۰۰۰ استفاده کنید.
--loose-date-filtering: هنگامی که یک بازه زمانی مشخص می‌شود، در صورتی که هر یک از ویرایش‌های ریزکد درون بازه زمانی باشد، تمام ویرایش‌های آن ریزکد برای انتخاب در نظر گرفته می‌شوند (تنها بازه تاریخی نادیده گرفته می‌شود و تمام فیلترهای دیگر همچنان اعمال می‌گردند).
--strict-date-filtering: هنگامی که یک بازه زمانی مشخص می‌شود، فقط ریزکدهایی که دقیقاً درون آن بازه زمانی هستند انتخاب می‌شوند. این حالت، شیوه عملکرد پیش‌فرض است.
-l, --list: فهرست کردن امضاهای ریزکدهای انتخاب‌شده در خروجی استاندارد (stdout).
-L, --list-all: فهرست کردن تمام امضاهای ریزکدها در هنگام پردازش در خروجی استاندارد (stdout).
-k[device], --kernel[=device]: بارگذاری ریزکدهای انتخاب‌شده در هسته. به‌صورت اختیاری، مسیر دستگاه قابل تعیین است (پیش‌فرض: /dev/cpu/microcode). این روش به‌روزرسانی منسوخ شده است: سرانجام از هسته و از iucode_tool حذف خواهد شد.
-K[directory], --write-firmware[=directory]: نوشتن ریزکدهای انتخاب‌شده با نام‌های فایلی که بارگذار میان‌افزار هسته لینوکس انتظار دارد. به‌صورت اختیاری می‌توان دایرکتوری مقصد را مشخص کرد (پیش‌فرض: /lib/firmware/intel‐ucode).
-wfile, --write-to=file: نوشتن ریزکدهای انتخاب‌شده در یک فایل با قالب باینری.
--write-earlyfw=file: نوشتن ریزکدهای انتخاب‌شده در یک بایگانی early initramfs که باید به ابتدای initramfs معمولی ضمیمه شود تا هسته بتواند در مراحل بسیار اولیه بوت سیستم، ریزکد پردازنده را به‌روزرسانی کند.
-Wdirectory, --write-named-to=directory: نوشتن ریزکدهای انتخاب‌شده در دایرکتوری مشخص‌شده، به ازای هر فایل یک ریزکد، با قالب باینری. نام فایل‌ها نشان‌دهنده امضای ریزکد، ماسک فلگ‌های پردازنده و ویرایش آن خواهد بود.
--write-all-named-to=directory: نوشتن تمامی ریزکدها در دایرکتوری مشخص‌شده، به ازای هر فایل یک ریزکد، با قالب باینری. نام فایل‌ها نشان‌دهنده امضای ریزکد، ماسک فلگ‌های پردازنده و ویرایش آن خواهد بود. این تنها راه برای نوشتن تمام ویرایش‌های یک ریزکد یکسان در خروجی است.
--overwrite: حذف فایل مقصد پیش از نوشتن، در صورتی که از قبل وجود داشته باشد و دایرکتوری نباشد. فایل مقصد درجا بازنویسی نمی‌شود. پیوندهای سخت (Hardlinks) گسسته خواهند شد و هرگونه دسترسی، ACL و سایر صفات گسترده فایل مقصد قبلی از بین خواهد رفت.
--no-overwrite: توقف اجرا در صورتی که فایل مقصد از قبل وجود داشته باشد. این حالت، شیوه عملکرد پیش‌فرض است. توجه داشته باشید که iucode_tool هنگام نوشتن فایل‌ها، از پیوندهای نمادین غیردایرکتوری تبعیت نمی‌کند.
--mini-earlyfw: بهینه‌سازی کانتینر cpio در early initramfs برای رسیدن به کمترین اندازه ممکن. این گزینه اندازه بلوک cpio را به ۱۶ بایت تغییر می‌دهد و ورودی‌های هدر دایرکتوری‌های والد فایل داده ریزکد را حذف می‌کند. در نتیجه، فایل داده ریزکد برای initramfs معمولی در دسترس نخواهد بود و ممکن است ابزارها نسبت به اندازه غیراستاندارد بلوک cpio اخطار دهند.

این کار معمولاً حجم early initramfs را ۷۳۶ بایت کاهش می‌دهد.

--normal-earlyfw: بهینه‌سازی اندازه early initramfs برای سازگاری با ابزارها. این حالت، شیوه عملکرد پیش‌فرض است. فایل داده ریزکد درون initramfs معمولی نیز در دسترس خواهد بود.

نکات (NOTES)

iucode_tool تمام داده‌ها را پیش از هرگونه پردازش در حافظه می‌خواند. این ابزار برای بررسی سلامت، حداکثر سقف ۱ گیبی‌بایت (1GiB) داده باینری ریزکد را برای هر فایل داده ریزکد اعمال می‌کند.

تمامی پیام‌های اطلاع‌رسانی و خطا به خطای استاندارد (stderr) ارسال می‌شوند، در حالی که خروجی‌های درخواست‌شده توسط کاربر (مانند خروجی تولیدشده توسط گزینه‌های فهرست‌بندی) به خروجی استاندارد (stdout) ارسال می‌گردند.

iucode_tool فایل‌ها را با مجوز 0644 (rw-r--r--) ایجاد می‌کند که بر اساس umask جاری تغییر می‌یابد.

فهرست ریزکدهای انتخاب‌شده و فایل‌های خروجی ریزکد در iucode_tool ابتدا بر اساس امضای پردازنده (صعودی) و سپس بر اساس ماسک فلگ‌های پردازنده (نزولی) مرتب می‌شوند.

هنگامی که چندین ویرایش از یک ریزکد انتخاب شوند، از نسخه‌های قدیمی‌تر صرف‌نظر می‌شود. تنها جدیدترین ویرایش انتخاب‌شده از یک ریزکد (یا در صورت فعال بودن گزینه --downgrade، آخرین ویرایش بر اساس ترتیب بارگذاری) درون فایل نوشته شده یا در هسته بارگذاری می‌شود.

فایل‌های داده ریزکد اینتل، چه در قالب باینری و چه در قالب متنی، می‌توانند به یکدیگر متصل شوند (الحاق شوند) تا یک فایل داده ریزکد بزرگ‌تر و همچنان معتبر تولید کنند.

iucode_tool هنگام نوشتن فایل‌های داده ریزکد از پیوندهای نمادین تبعیت نمی‌کند. این ابزار یا از نوشتن فایل خودداری کرده و متوقف می‌شود (شیوه عملکرد پیش‌فرض)، یا (در صورت فعال بودن گزینه --overwrite) پیوند نمادین یا فایل مقصد را پیش از نوشتن فایل جدید حذف می‌کند (و در نتیجه پیوندهای سخت را می‌شکند).

iucode_tool از پیوندهای نمادین دایرکتوری برای یافتن دایرکتوری جهت نوشتن فایل‌ها تبعیت می‌کند.

نکات لینوکس (Linux Notes)

پیش از نسخه 4.4 لینوکس، درایور به‌روزرسانی ریزکد به دو بخش تقسیم شده بود: درایور به‌روزرسانی زودهنگام ریزکد (early microcode update driver که داده‌های ریزکد را از initramfs دریافت می‌کرد) و درایور به‌روزرسانی دیرهنگام ریزکد (late microcode update driver که می‌توانست یک ماژول باشد و داده‌های ریزکد را از زیرسیستم میان‌افزار دریافت می‌کرد). این دو درایور در نسخه 4.4 لینوکس یکپارچه شدند.

درایور به‌روزرسانی ریزکد باید همیشه در سیستم حضور داشته باشد تا اطمینان حاصل شود که به‌روزرسانی‌های ریزکد پس از بازگشت از حالت تعلیق (resume from suspend) و اتصال گرم پردازنده (CPU hotplug) مجدداً اعمال می‌شوند. ماژول ریزکد را تخلیه (unload) نکنید، مگر اینکه واقعاً دلیل فنی موجهی داشته باشید. از لینوکس نسخه 4.4 به بعد، درایور به‌روزرسانی دیرهنگام دیگر نمی‌تواند یک ماژول باشد و در صورت فعال بودن، همواره در سیستم حضور خواهد داشت.

به‌روزرسانی زودهنگام ریزکد امن‌تر است. این کار فقط در زمان بوت امکان‌پذیر است و به یک initramfs نیاز دارد، اما به‌شدت توصیه می‌شود: به‌روزرسانی‌های دیرهنگام ریزکد (که داده‌های ریزکد را از مسیر ‎/lib/firmware می‌خوانند) نمی‌توانند ویژگی‌های قابل مشاهده پردازنده را با ایمنی تغییر دهند.

به‌روزرسانی‌های زودهنگام ریزکد از نسخه 3.9 لینوکس در دسترس هستند. آن‌ها می‌توانند ویژگی‌های قابل مشاهده پردازنده را با ایمنی تغییر دهند (همانند به‌روزرسانی‌های ریزکدی که دستورالعمل‌های Intel TSX را در هسته‌های Intel Haswell غیرفعال کردند). این به‌روزرسانی‌ها به یک ایمیج initramfs فشرده‌نشده حاوی داده‌های به‌روزرسانی ریزکد در مسیر /kernel/x86/microcode/GenuineIntel.bin نیاز دارند. این ایمیج initramfs فشرده‌نشده باید قبل از هر ایمیج فشرده‌نشده/فشرده‌شده دیگر initramfs قرار گیرد و نام ویژه‌ای دارد: early initramfs.

داده‌های به‌روزرسانی ریزکد درون ایمیج early initramfs به دلیل وجود یک باگ در چندین نسخه از درایور به‌روزرسانی زودهنگام ریزکد هسته لینوکس، باید روی مرز ۱۶ بایتی تراز (aligned) شوند. این امر نیازمند مراحل ویژه‌ای هنگام ساخت آرشیو initramfs حاوی داده‌های ریزکد است و به‌صورت خودکار توسط گزینه --write-earlyfw در iucode_tool مدیریت می‌شود.

از لینوکس نسخه 4.2، امکان ساخت هسته همراه با داده‌های به‌روزرسانی ریزکد به‌صورت میان‌افزار توکار (built-in firmware) با استفاده از قابلیت CONFIG_FIRMWARE_IN_KERNEL نیز فراهم شده است. این قابلیت تا نسخه‌های 4.2.8، 4.4.11، 4.5.5 و 4.6 لینوکس هنوز کاملاً به بلوغ نرسیده بود و ممکن است در تمام موارد کار نکند.

رابط به‌روزرسانی /dev/cpu/microcode منسوخ شده و نباید استفاده شود. این رابط یک الزام خاص دارد: هر فراخوانی سیستمی write باید شامل کل ریزکد(ها) باشد. این رابط از طریق iucode_tool با گزینه --kernel قابل دسترسی است.

تا نسخه 3.5 لینوکس، به‌روزرسانی دیرهنگام ریزکد باید برای هر هسته به‌صورت جداگانه، با نوشتن عدد ۱ در /sys/devices/system/cpu/*/microcode/reload برای هر پردازنده اعمال می‌شد. بسته به نسخه هسته، باید آن را روی هر هسته اعمال می‌کردید تا از وضعیت خطرناکی که برخی هسته‌ها از ریزکد قدیمی استفاده می‌کنند جلوگیری شود، یا اینکه هسته درخواست را فقط برای پردازنده بوت می‌پذیرفت و از آن برای راه‌اندازی به‌روزرسانی در تمام هسته‌های پردازنده سیستم استفاده می‌کرد.

از نسخه 3.6 لینوکس، درایور به‌روزرسانی دیرهنگام ریزکد دارای یک رابط جدید است که با نوشتن عدد ۱ در /sys/devices/system/cpu/microcode/reload به‌طور صریح به‌روزرسانی را برای تمامی هسته‌ها به‌طور هم‌زمان فعال می‌کند.

مثال‌ها (EXAMPLES)

به‌روزرسانی فایل‌ها در /lib/firmware/intel‐ucode:

iucode_tool -K/lib/firmware/intel-ucode \
/lib/firmware/intel-ucode \
/tmp/file-with-new-microcodes.bin

پردازش هم‌زمان چندین فایل فشرده:

zcat intel-microcode*.dat.gz | iucode_tool -l -

zcat intel-microcode*.bin.gz | iucode_tool -l -tb -

انتخاب ریزکدها و ایجاد یک early initramfs:

iucode_tool --scan-system \
--write-earlyfw=/tmp/early.cpio \
/lib/firmware/intel-ucode

iucode_tool -s 0x106a5 -s 0x106a4 -l /lib/firmware/intel-ucode

استفاده از بارگذار بازیابی برای بارگذاری و به‌روزرسانی ریزکد در early initramfs:

iucode_tool -L -tr /boot/intel-ucode.img

iucode_tool -Ll -S --write-earlyfw=/boot/intel-ucode.img.new \
-tr /boot/intel-ucode.img -tb /lib/firmware/intel-ucode && \
mv /boot/intel-ucode.img.new /boot/intel-ucode.img

اشکالات (BUGS)

برای ریزکدهای با شماره ویرایش منفی حالت خاصی در نظر گرفته نشده است و نسبت به ریزکدهای معمولی ترجیح داده نخواهند شد.

حالت تقلیل نسخه (downgrade mode) فقط باید برای ریزکدهایی با ماسک فلگ‌های پردازنده یکسان استفاده شود. این حالت نمی‌تواند موارد نادری را که در آن‌ها تغییر ماسک فلگ‌های پردازنده برای اجبار هسته به بارگذاری ویرایش پایین‌تر ریزکد لازم است مدیریت کند، و در چنین شرایطی iucode_tool یک پیام هشدار صادر خواهد کرد. تاکنون، این مورد محدودیت مهمی به شمار نرفته است زیرا تغییرات در ماسک فلگ‌های پردازنده در به‌روزرسانی‌های ریزکدِ مرحله تولید و پس از عرضه بسیار نادر است.

فیلد متادیتای نسخه بارگذار (loader version) ریزکد توسط iucode_tool نادیده گرفته می‌شود. تا زمانی که یک امضا به بیش از یک نوع بارگذار نیاز نداشته باشد، این موضوع نباید مشکلی ایجاد کند.

فایل‌ها به‌صورت اتمیک (atomic) جایگزین نمی‌شوند: اگر اجرای iucode_tool هنگام نوشتن در یک فایل متوقف شود، آن فایل آسیب خواهد دید.

همچنین ببینید (SEE ALSO)

The Intel 64 and IA‐32 Architectures Software Developer's Manual, Volume 3A: System Programming Guide, Part 1 (order number 253668), section 9.11.

نویسنده (AUTHOR)

Henrique de Moraes Holschuh <hmh@hmh.eng.br>