در این مقاله از BIOS قدیمی تا UEFI UEFI دقیقا چیست؟ مسیر کلی Boot در یک سیستم امروزی Boot Manager و NVRAM EFI System Partition چیست؟ GPT چه ربطی به UEFI دارد؟ یک مثال واقعی از Windows Secure Boot کجای مسیر قرار می گیرد؟ چه زمانی Firmware کنار می رود؟ عمیق تر: SEC، PEI، DXE و BDS

در مقاله های قبلی درباره Boot در کامپیوترهای x86، BIOS، Real Mode و مسیر کلاسیک شروع سیستم صحبت کردیم. اما اگر امروز یک کامپیوتر جدید را روشن کنیم، در بیشتر موارد دیگر آن مدل قدیمی BIOS و اجرای Boot Code از MBR، مسیر اصلی Boot نیست.

در سیستم های امروزی معمولا با UEFI روبه رو هستیم. UEFI فقط یک منوی تنظیمات جدید یا نسخه گرافیکی BIOS نیست. تفاوت اصلی بسیار عمیق تر است و به این بر می گردد که Firmware چگونه سخت افزار را برای Boot آماده می کند، چگونه Bootloader سیستم عامل را پیدا می کند و چه رابط استانداردی در اختیار آن قرار می دهد. 

Power
  ↓
CPU reset / platform initialization
  ↓
Firmware initializes the platform
  ↓
UEFI environment becomes available
  ↓
UEFI Boot Manager
  ↓
EFI OS loader
  ↓
Operating-system loader
  ↓
Kernel
  ↓
Operating system

این نمودار عمدا ساده شده است. داخل خود Firmware ممکن است مراحل زیادی قبل از رسیدن به Boot Manager وجود داشته باشد. در بخش «عمیق تر بشویم» به یکی از معماری های رایج برای همین مراحل داخلی بر می گردیم.

از BIOS قدیمی تا UEFI، چه چیزی عوض شد؟

مدل قدیمی PC BIOS در دوره ای شکل گرفت که سخت افزار کامپیوتر بسیار ساده تر بود. در مسیر کلاسیک، Firmware پس از آماده سازی اولیه سیستم یک دستگاه Boot را انتخاب می کرد، اولین سکتور آن را می خواند و اجرای Boot Code کوچک موجود در آن را شروع می کرد. در دیسک های MBR این Boot Code بخشی از همان ساختار ابتدایی دیسک بود.

UEFI این مدل را تغییر می دهد. Firmware دیگر برای Boot شدن سیستم عامل مجبور نیست فقط یک تکه کد کوچک را از اولین سکتور دیسک اجرا کند. UEFI می تواند ساختار پارتیشن را بفهمد، File System تعریف شده برای محیط EFI را بخواند و یک فایل اجرایی EFI را مانند یک فایل واقعی پیدا و Load کند. در UEFI Specification صراحتا آمده است که EFI Firmware، کد موجود در MBR را برای Boot اجرا نمی کند.

این تغییر مهم است چون Boot از حالت «چند صد بایت کد در ابتدای دیسک» به محیطی تبدیل می شود که Firmware می تواند فایل ها، Device Pathها، Boot Entryها، Driverها و Applicationهای UEFI را مدیریت کند.

⭐ تفاوت اصلی را این طور به خاطر بسپاریم

در Legacy BIOS، Boot به شکل تاریخی به Boot Code سکتورهای ابتدایی دیسک وابسته بود. در UEFI، Firmware می تواند مستقیما یک فایل اجرایی EFI را از File System مناسب پیدا و اجرا کند.

UEFI دقیقا چیست؟

یک نکته مهم این است که UEFI نام یک Firmware مشخص نیست. UEFI در اصل یک Specification است که رابط بین Platform Firmware و سیستم عامل یا OS Loader را تعریف می کند. یعنی سازنده مادربرد یا سیستم می تواند Firmware خودش را پیاده سازی کند، اما اگر آن Firmware با UEFI سازگار باشد، مجموعه مشخصی از Interfaceها، Data Structureها و Serviceها را ارائه می دهد.

پس وقتی در صحبت روزمره می گوییم «این کامپیوتر UEFI دارد»، منظورمان این است که Firmware آن سیستم محیط و رابط های تعریف شده توسط UEFI را فراهم می کند.

این محیط فقط برای Bootloader نیست. UEFI مفاهیمی مثل Boot Services، Runtime Services، Device Protocolها، UEFI Driverها و UEFI Applicationها را هم تعریف می کند. به همین دلیل یک UEFI Application می تواند قبل از بالا آمدن سیستم عامل اجرا شود و از سرویس های Firmware استفاده کند.

نکته جالب دیگر این است که داشتن محیط گرافیکی، Mouse یا ظاهر مدرن شرط UEFI بودن نیست. ممکن است Firmware یک سیستم کاملا متنی باشد و همچنان UEFI را پیاده سازی کند. بنابراین «BIOS قدیمی متنی بود، UEFI گرافیکی است» توضیح درستی برای تفاوت این دو نیست.

مسیر کلی Boot در یک سیستم امروزی

بعد از فشردن دکمه Power، CPU نمی تواند مستقیما Windows یا Linux را اجرا کند. ابتدا Platform Firmware باید محیط سخت افزاری را به اندازه کافی آماده کند. جزئیات این مرحله به پردازنده، Chipset، مادربرد و پیاده سازی Firmware بستگی دارد.

در یک نمایش ساده می توان مسیر را این طور دید: 

Power
  ↓
CPU begins from its defined reset state
  ↓
Early firmware code runs
  ↓
Memory and essential platform hardware become usable
  ↓
Firmware discovers and initializes devices
  ↓
UEFI Boot Manager runs
  ↓
A boot option is selected
  ↓
UEFI loads an EFI executable
  ↓
OS loader prepares the operating system
  ↓
Kernel takes control

عبارت «UEFI starts» در این نمودار یک لحظه جادویی و واحد نیست. بخش زیادی از Firmware پیش از رسیدن به Boot Manager در حال آماده کردن Platform است. UEFI بیشتر رابط استاندارد و محیطی را تعریف می کند که اجزای Boot در نهایت از آن استفاده می کنند.

Boot Manager و NVRAM، Firmware از کجا می داند چه چیزی را Boot کند؟

در UEFI یک Boot Manager وجود دارد. این بخش از Firmware مسئول انتخاب و Load کردن Boot Optionها است. ترتیب Boot فقط یک لیست ظاهری در صفحه Setup نیست، پشت آن Variableهای استاندارد UEFI قرار دارند که معمولا در حافظه Non-volatile سیستم نگهداری می شوند.

دو نام مهم در اینجا BootOrder و Boot#### هستند. هر Boot#### یک Boot Entry را توصیف می کند و می تواند شامل Device Path، مسیر Loader و اطلاعات مربوط به آن Boot Option باشد. BootOrder ترتیب تلاش برای این Entryها را مشخص می کند.

مثلا ممکن است Firmware Entryهایی شبیه این داشته باشد: 

Boot0000  Windows Boot Manager
Boot0001  Linux
Boot0002  UEFI USB Device
Boot0003  UEFI Network

BootOrder: 0000,0001,0002,0003

این فقط یک مثال مفهومی است و شماره ها روی هر سیستم می توانند متفاوت باشند. نکته اصلی این است که UEFI Boot Manager لازم نیست با حدس زدن سکتور اول دیسک سیستم عامل را پیدا کند. Firmware می تواند Boot Option مشخصی داشته باشد که به یک Loader مشخص اشاره می کند.

🔍 عمیق تر بشویم: NVRAM در اینجا یعنی چه؟

UEFI مجموعه ای از Variableها را تعریف می کند که بعضی از آنها با ویژگی Non-volatile ذخیره می شوند، یعنی با خاموش شدن عادی سیستم از بین نمی روند. Boot Entryها، BootOrder و بسیاری از تنظیمات مرتبط با Secure Boot از همین سازوکار استفاده می کنند.

این به معنی وجود یک تراشه جداگانه با نام «NVRAM مخصوص UEFI» در همه سیستم ها نیست. روش فیزیکی ذخیره سازی به پیاده سازی Firmware بستگی دارد. چیزی که UEFI استاندارد می کند Interface و رفتار Variableها است.

EFI System Partition چیست؟

اگر UEFI قرار است یک فایل Bootloader را از دیسک پیدا کند، به جایی نیاز دارد که بتواند File System آن را بخواند. اینجاست که ESP وارد داستان می شود.

ESP یک پارتیشن کوچک سیستمی است که فایل های موردنیاز برای Boot در محیط UEFI را نگه می دارد. در یک Hard Disk استاندارد، داخل ریشه این پارتیشن Directoryای با نام EFI وجود دارد و Vendorها یا سیستم عامل ها Subdirectory خودشان را زیر آن می سازند.

برای مثال ساختار یک سیستم می تواند مفهومی شبیه این داشته باشد: 

\EFI
   ├── Microsoft
   │     └── Boot
   │          └── bootmgfw.efi
   │
   ├── ubuntu
   │     └── shimx64.efi
   │
   └── BOOT
         └── BOOTX64.EFI

همه سیستم ها دقیقا چنین ساختاری ندارند، اما ایده اصلی ثابت است: فایل های اجرایی با پسوند .efi می توانند در این محیط توسط Firmware یا دیگر UEFI Applicationها Load شوند.

UEFI برای System Partition روی دیسک، File System مبتنی بر FAT را تعریف می کند و Firmware باید Variantهای تعریف شده EFI FAT را پشتیبانی کند. در PCهای امروزی ESP روی Disk سیستم معمولا FAT32 است و Microsoft نیز برای Windows روی سیستم های UEFI، FAT32 را برای ESP الزام می کند.

🛠 چرا ESP معمولا داخل File Explorer دیده نمی شود؟

در Windows این پارتیشن معمولا Drive Letter ندارد. بنابراین وجود دارد و برای Boot حیاتی است، اما کاربر در استفاده روزمره آن را کنار درایو C نمی بیند.

GPT چه ربطی به UEFI دارد؟

UEFI و GPT دو مفهوم جدا هستند، هرچند در PCهای امروزی معمولا کنار هم دیده می شوند.

GPT یک Partitioning Scheme است. یعنی ساختاری را تعریف می کند که پارتیشن های یک Disk چگونه توصیف شوند. در مقایسه با MBR قدیمی، GPT از آدرس های بزرگ تر استفاده می کند، برای تعداد بیشتری Partition طراحی شده، نسخه Primary و Backup از Partition Table دارد و برای تشخیص خرابی ساختارها از CRC استفاده می کند.

اما نباید نتیجه بگیریم که «UEFI یعنی GPT و بس». UEFI Specification ساختارهای GPT و Legacy MBR را برای کشف Partitionها تعریف می کند و Firmware می تواند هر دو نوع را تشخیص دهد. رابطه این دو بیشتر این است که GPT بخشی از معماری مدرن Storage و Boot در اکوسیستم UEFI شده است.

در Windows موضوع مشخص تر است: وقتی Windows را در حالت UEFI روی System Disk نصب می کنیم، Microsoft برای آن Disk استفاده از GPT را الزامی می داند و EFI System Partition روی همان ساختار ایجاد می شود. 

GPT disk

LBA 0
  Protective MBR
      ↓
LBA 1
  Primary GPT Header
      ↓
GPT Partition Entries
      ↓
Partitions
  ├── EFI System Partition
  ├── OS / Data partitions
  └── Recovery / other partitions
      ↓
Last area of disk
  Backup GPT structures

وجود Protective MBR در LBA 0 هم نکته جالبی است. هدف آن Boot کردن سیستم UEFI نیست. این ساختار برای سازگاری با ابزارهای قدیمی قرار می گیرد تا دیسک GPT را اشتباها یک Disk خالی تصور نکنند. UEFI در حالت معمول Boot Code داخل این MBR را اجرا نمی کند.

یک مثال واقعی، Windows در UEFI چگونه پیدا می شود؟

در یک Windows نصب شده در حالت UEFI، Windows Boot Manager یک EFI Application است. مسیر رایج آن روی EFI System Partition این است: 

\EFI\Microsoft\Boot\bootmgfw.efi

Firmware یک Boot Entry برای Windows Boot Manager در Variableهای UEFI دارد. وقتی این Entry انتخاب می شود، Firmware فایل EFI مربوط را Load می کند و کنترل را به آن می دهد. از آن لحظه به بعد خود Windows Boot Manager ادامه مسیر Windows را مدیریت می کند.

اگر مسیر را کمی دقیق تر ببینیم: 

UEFI Firmware
  ↓
UEFI Boot Manager
  ↓
Windows Boot Manager
\EFI\Microsoft\Boot\bootmgfw.efi
  ↓
Windows OS Loader
winload.efi
  ↓
Windows kernel
ntoskrnl.exe

این مسیر نشان می دهد که دو عبارت شبیه به هم را نباید یکی بدانیم: UEFI Boot Manager بخشی از Firmware است، اما Windows Boot Manager نرم افزار Microsoft است که Firmware آن را به عنوان یک EFI Application اجرا می کند.

🔍 عمیق تر بشویم: اگر Boot Entryها از بین بروند چه می شود؟

UEFI برای Boot از Removable Media و برخی حالت های Recovery مسیرهای پیش فرض هم تعریف می کند. روی معماری x86-64 یکی از نام های آشنا \EFI\BOOT\BOOTX64.EFI است. به همین دلیل یک USB نصب سیستم عامل می تواند بدون داشتن Boot Entry دائمی قبلی در NVRAM نیز قابل Boot باشد.

Secure Boot کجای این مسیر قرار می گیرد؟

یکی از اشتباه های رایج این است که UEFI و Secure Boot را یک چیز بدانیم. این دو یکی نیستند. یک سیستم می تواند UEFI باشد و Secure Boot روی آن غیرفعال باشد.

Secure Boot قابلیتی امنیتی در اکوسیستم UEFI است که وقتی فعال باشد، Firmware قبل از اجرای UEFI Imageهای مشمول Policy، اعتبار آنها را بررسی می کند. در ساده ترین بیان، Firmware می خواهد مطمئن شود کدی که قرار است پیش از سیستم عامل اجرا شود طبق Policy سیستم مورداعتماد است و در فهرست منع شده قرار ندارد.

UEFI برای این Policy مجموعه Variableها و Signature Databaseهایی تعریف می کند. نام هایی مثل PK، KEK، db و dbx در همین بخش دیده می شوند. برای فهم مسیر کلی Boot لازم نیست وارد جزئیات Cryptography آنها شویم، فقط باید بدانیم که Secure Boot در مرحله Load شدن Imageهای UEFI یک لایه بررسی اعتماد اضافه می کند. 

Boot Manager selects EFI image
            ↓
      Secure Boot enabled?
        ┌───┴───┐
       No      Yes
       ↓        ↓
     Load    Validate image
                ↓
          trusted by policy?
             ┌──┴──┐
            No    Yes
            ↓      ↓
          Block   Load

بنابراین Secure Boot قرار نیست فایل های شخصی کاربر را Encrypt کند و جای BitLocker هم نیست. وظیفه اصلی آن محافظت از زنجیره اعتماد در بخش های ابتدایی Boot است.

چه زمانی Firmware کنار می رود؟

تا زمانی که OS Loader داخل محیط UEFI فعالیت می کند، می تواند از UEFI Boot Services برای کارهایی مثل دسترسی به Memory Map، Load کردن Imageها و استفاده از Protocolهای ارائه شده توسط Firmware کمک بگیرد.

اما قرار نیست Firmware برای همیشه کنترل اجرای سیستم را در اختیار داشته باشد. وقتی OS Loader آماده شد که سیستم عامل را واقعا تحویل بگیرد، تابعی با نام ExitBootServices() را فراخوانی می کند. با موفق شدن این فراخوانی، Boot Services پایان پیدا می کنند و از آن نقطه OS Loader مسئول ادامه کار سیستم است. 

UEFI environment
  ↓
OS loader uses Boot Services
  ↓
Kernel and memory state are prepared
  ↓
ExitBootServices()
  ↓
Boot Services end
  ↓
OS owns the machine
  ↓
Kernel continues startup

با این حال UEFI کاملا ناپدید نمی شود. بعضی Runtime Services برای استفاده سیستم عامل پس از پایان Boot Services نیز تعریف شده اند. برای مثال Variable Services و Reset System از خانواده Runtime Services هستند.

⭐ چیزی که از این بخش باید بماند

UEFI فقط کدی نیست که سیستم عامل را پیدا کند. قبل از تحویل کنترل، یک محیط استاندارد با Serviceها و Protocolهای مشخص در اختیار OS Loader قرار می دهد. سپس OS Loader با ExitBootServices() پایان مرحله Boot Services را اعلام می کند و کنترل اصلی سیستم را می گیرد.

🔍 عمیق تر بشویم: SEC، PEI، DXE و BDS دقیقا چه هستند؟

اگر درباره UEFI بیشتر مطالعه کنید خیلی زود با چهار نام SEC، PEI، DXE و BDS روبه رو می شوید. اینجا یک ظرافت مهم وجود دارد: این نام ها را نباید به عنوان «چهار مرحله اجباری خود UEFI در همه دستگاه های دنیا» معرفی کرد.

این مراحل متعلق به PI Architecture هستند. PI Specification مجموعه Interfaceهای داخلی Firmware را تعریف می کند، در حالی که UEFI Specification بیشتر Interface قابل مشاهده برای OS Loader و سیستم عامل را استاندارد می کند. بسیاری از Firmwareهای PC و پروژه هایی مثل EDK II از معماری PI استفاده می کنند، بنابراین این Phaseها در دنیای PC بسیار مهم اند.

🔍 عمیق تر بشویم: چهار Phase معروف در PI Architecture

SEC — Security Phase

نخستین Phase معماری PI است. سیستم هنوز منابع بسیار محدودی دارد. SEC رویدادهای Reset را مدیریت می کند، یک محیط اولیه و حافظه موقت لازم را فراهم می کند و اطلاعات موردنیاز را برای ورود به PEI آماده می کند. نام Security در اینجا نباید ما را به این نتیجه برساند که SEC همان Secure Boot است. این دو مفهوم متفاوت اند.

PEI — Pre-EFI Initialization

PEI باید Platform را به حداقلی برساند که مرحله بعد بتواند اجرا شود. یکی از مهم ترین وظایف معمول آن آماده کردن Permanent Memory است. اطلاعات وضعیت سیستم از طریق ساختارهایی به نام HOB به DXE منتقل می شود.

DXE — Driver Execution Environment

بخش بزرگی از Initialization سیستم در DXE انجام می شود. DXE Driverها اجزای مختلف Platform را آماده می کنند و بسیاری از سرویس ها و Protocolهایی که محیط UEFI به آنها نیاز دارد در این مرحله شکل می گیرند. اینجا Firmware از یک محیط بسیار ابتدایی به محیطی بسیار کامل تر تبدیل شده است.

BDS — Boot Device Selection

DXE و BDS با هم Platform را به نقطه Boot سیستم عامل می رسانند. در این ناحیه Boot Policy اجرا می شود، Consoleها و Boot Deviceهای لازم آماده می شوند و در نهایت Boot Option مناسب انتخاب می شود. از دید کاربر این همان بخشی است که کم کم به Boot Manager و انتخاب Loader سیستم عامل نزدیک می شویم.

پس اگر بخواهیم دو لایه را از هم جدا کنیم: 

Inside firmware implementation
──────────────────────────────
SEC → PEI → DXE → BDS
        PI Architecture

              ↓

OS-visible firmware interface
──────────────────────────────
UEFI Boot Manager
UEFI Boot Services
UEFI Runtime Services
UEFI Protocols
UEFI OS Loader interface

این تفکیک کمک می کند یک اشتباه رایج پیش نیاید: UEFI و PI به هم مرتبط اند، اما یک Specification واحد با یک Scope یکسان نیستند. UEFI مرز استاندارد بین Firmware و نرم افزار Boot شونده را تعریف می کند، PI بیشتر درباره معماری و همکاری اجزای داخلی Firmware در زمان Platform Initialization صحبت می کند.

پس از فشردن Power واقعا چه اتفاقی افتاد؟

حالا می توانیم کل داستان را یک بار بدون جزئیات اضافه مرور کنیم. 

1. Power is applied
        ↓
2. CPU begins from its reset-defined state
        ↓
3. Early firmware initializes enough of the platform
        ↓
4. Memory and required hardware become available
        ↓
5. Firmware drivers and devices are initialized
        ↓
6. UEFI Boot Manager reads boot policy / BootOrder
        ↓
7. A boot option points to an EFI loader
        ↓
8. Loader is read from a supported device / file system
        ↓
9. If Secure Boot is active, image trust is checked
        ↓
10. OS loader runs using UEFI Boot Services
        ↓
11. OS loader prepares the kernel
        ↓
12. ExitBootServices()
        ↓
13. Operating system takes control

در Windows یک مسیر رایج در میانه این زنجیره چنین است: 

UEFI Boot Manager
   ↓
\EFI\Microsoft\Boot\bootmgfw.efi
   ↓
winload.efi
   ↓
Windows kernel

این مدل دیگر به اجرای Boot Code داخل MBR وابسته نیست. Firmware می داند Partition و File System چیست، Boot Entry دارد، فایل EFI را Load می کند و یک محیط استاندارد برای ارتباط Loader با Firmware فراهم می کند.

⭐ چیزی که از این مقاله باید بماند

UEFI فقط جایگزین صفحه تنظیمات BIOS نیست. یک Interface استاندارد بین Firmware و نرم افزار Boot شونده است. Firmware سیستم را آماده می کند، Boot Manager بر اساس Boot Entryهای ذخیره شده Loader مناسب را پیدا می کند، Loader می تواند از EFI System Partition به صورت یک فایل واقعی اجرا شود و در پایان با ExitBootServices() کنترل اصلی به سیستم عامل منتقل می شود.

GPT، ESP و Secure Boot معمولا در کنار UEFI دیده می شوند، اما هیچ کدام دقیقا مترادف UEFI نیستند.

واژه نامه کوتاه

UEFI
Unified Extensible Firmware Interface، Specification و محیط استاندارد ارتباط Firmware با OS Loader و سیستم عامل.
Firmware
نرم افزار سطح پایینی که Platform را پیش از سیستم عامل آماده و مدیریت می کند.
Boot Manager
بخش Firmware که Boot Optionها را بررسی می کند و Loader مناسب را انتخاب و اجرا می کند.
NVRAM
در این بحث، محل منطقی نگهداری Variableهای Non-volatile مثل Boot Entryها و BootOrder.
ESP
EFI System Partition، پارتیشنی که فایل ها و UEFI Imageهای موردنیاز Boot می توانند در آن قرار بگیرند.
GPT
GUID Partition Table، روش مدرن توصیف Partitionهای Disk با GUID، Header اصلی و Backup و بررسی CRC.
EFI Application
فایل اجرایی سازگار با محیط UEFI که Firmware می تواند آن را Load و اجرا کند. OS Loader هم می تواند یک UEFI Application باشد.
Secure Boot
قابلیت امنیتی UEFI برای بررسی اعتماد UEFI Imageها طبق Policy و Signature Databaseهای سیستم.
Boot Services
Serviceهای UEFI که پیش از موفق شدن ExitBootServices در دسترس Loaderها و دیگر UEFI Imageها هستند.
Runtime Services
بخشی از Serviceهای UEFI که پس از تحویل کنترل به سیستم عامل نیز می توانند در دسترس بمانند.
PI
Platform Initialization، Specification مرتبط با معماری و Interfaceهای داخلی Firmware در مراحل Initialization.

منابع رسمی برای مطالعه و بازبینی بیشتر