Unified Extensible Firmware Interface - Unified Extensible Firmware Interface

Pozice EFI v zásobníku softwaru

Unified Extensible Firmware Interface ( UEFI ) je veřejně dostupná specifikace , která definuje softwarové rozhraní mezi operačním systémem a platformy firmware . UEFI nahrazuje starší rozhraní firmwaru BIOS (Basic Input/Output System ) původně přítomné ve všech osobních počítačích kompatibilních s IBM PC , přičemž většina implementací firmwaru UEFI poskytuje podporu starších služeb BIOS. UEFI může podporovat vzdálenou diagnostiku a opravy počítačů, a to i bez nainstalovaného operačního systému.

Intel vyvinul původní specifikace Extensible Firmware Interface ( EFI ). Některé postupy a datové formáty EFI zrcadlí ty z Microsoft Windows . V roce 2005 UEFI zamítlo EFI 1.10 (konečné vydání EFI). Unified EFI Forum je průmyslový subjekt, který řídí specifikace UEFI v celém textu.

Dějiny

Původní motivace pro EFI přišla během raného vývoje prvních systémů Intel – HP Itanium v polovině 90. let. Omezení systému BIOS (jako 16bitový reálný režim , 1 MB adresovatelného paměťového prostoru, programování v jazyce sestavení a hardware PC AT ) se stala příliš restriktivní pro větší serverové platformy, na které Itanium cílil. Snaha řešit tyto obavy začala v roce 1998 a původně se nazývala Intel Boot Initiative . Později byl přejmenován na Extensible Firmware Interface (EFI).

V červenci 2005 společnost Intel ukončila vývoj specifikace EFI ve verzi 1.10 a přispěla do Unified EFI Forum , které tuto specifikaci vyvinulo jako Unified Extensible Firmware Interface (UEFI). Původní specifikace EFI zůstává ve vlastnictví společnosti Intel, která poskytuje výhradně licence pro produkty založené na EFI, ale specifikaci UEFI vlastní fórum UEFI.

Verze 2.0 specifikace UEFI byla vydána 31. ledna 2006. Přidala kryptografii a zabezpečení. Verze 2.1 specifikace UEFI byla vydána 7. ledna 2007. Přidala autentizaci sítě a architekturu uživatelského rozhraní (v UEFI „Infrastruktura lidského rozhraní“).

Poslední specifikace UEFI, verze 2.9, byla zveřejněna v březnu 2021.

První implementace open source UEFI, Tiano, byla vydána společností Intel v roce 2004. Od té doby byl Tiano nahrazen EDK a EDK2 a nyní je spravován komunitou TianoCore.

V prosinci 2018 společnost Microsoft oznámila Project Mu, vidlici TianoCore EDK2 používanou v produktech Microsoft Surface a Hyper-V . Projekt propaguje myšlenku firmwaru jako služby .

V říjnu 2018 společnost Arm oznámila Arm ServerReady , certifikační program shody pro přistání generických běžných operačních systémů a hypervisorů na servery založené na Arm. Program vyžaduje, aby systémový firmware vyhovoval požadavkům SBBR (Server Base Boot Requirements). SBBR vyžaduje kompatibilitu s UEFI, ACPI a SMBIOS . V říjnu 2020 společnost Arm oznámila rozšíření programu na trh Edge a IoT . Nový název programu je Arm SystemReady . Arm SystemReady definoval specifikaci Base Boot Requirements ( BBR ), která v současné době poskytuje tři recepty, z nichž dva souvisejí s UEFI: 1) SBBR: který vyžaduje kompatibilitu UEFI, ACPI a SMBIOS vhodnou pro operační prostředí podnikové úrovně, jako jsou Windows, Red Hat Enterprise Linux, VMware ESXi; a 2) EBBR: který vyžaduje soulad se sadou rozhraní UEFI definovaných v Embedded Base Boot Requirements ( EBBR ) vhodných pro vestavěné prostředí, jako je Yocto. Mnoho distribucí Linuxu a BSD může podporovat oba recepty.

Výhody

Rozhraní definované specifikací EFI obsahuje datové tabulky, které obsahují informace o platformě, a spouštěcí a běhové služby, které jsou k dispozici pro zavaděč OS a OS. Firmware UEFI poskytuje oproti tradičnímu systému BIOS několik technických výhod:

  • Možnost zavést disk obsahující velké oddíly (přes 2  TB ) pomocí tabulky oddílů GUID (GPT)
  • Flexibilní prostředí před OS, včetně možnosti sítě, GUI, více jazyků
  • 32bitové (například IA-32 , ARM32 ) nebo 64bitové (například x64 , AArch64 ) prostředí před OS
  • Programování v jazyce C.
  • Modulární design
  • Zpětná a dopředná kompatibilita

Kompatibilita

Kompatibilita procesoru

Od verze 2.5 existují vazby procesorů pro Itanium, x86, x86-64, ARM (AArch32) a ARM64 (AArch64). Podporovány mohou být pouze procesory small-endian . Neoficiální podpora UEFI se vyvíjí pro POWERPC64 implementací TianoCore na OPAL, abstrakční vrstvu OpenPOWER, běžící v režimu little-endian. Podobné projekty existují pro MIPS a RISC-V . Od verze UEFI 2.7 byly oficiálně zavedeny vazby procesoru RISC-V pro 32-, 64- a 128bitové režimy.

Standardní PC BIOS je omezen na režim 16bitového procesoru a 1 MB adresovatelného paměťového prostoru, což vyplývá z návrhu založeného na IBM 5150, který používal 16bitový procesor Intel 8088 . Pro srovnání, režim procesoru v prostředí UEFI může být buď 32bitový ( x86-32 , AArch32) nebo 64bitový ( x86-64 , Itanium a AArch64). 64bitové implementace firmwaru UEFI podporují dlouhý režim , který umožňuje aplikacím v prostředí před spuštěním používat 64bitové adresování a získat tak přímý přístup do celé paměti stroje.

UEFI vyžaduje, aby firmware a zavaděč operačního systému (nebo jádro) odpovídaly velikosti; to znamená, že 64bitová implementace firmwaru UEFI může načíst pouze 64bitový zavaděč operačního systému (OS) nebo jádro (pokud není použito spouštění Legacy založené na CSM) a totéž platí pro 32bitové. Po přechodu systému z „Boot Services“ na „Runtime Services“ převezme jádro operačního systému. V tomto okamžiku může jádro změnit režimy procesoru, pokud si to přeje, ale to omezuje využití runtime služeb (pokud se jádro znovu nepřepne). Od verze 3.15 podporuje linuxové jádro 64bitová jádra, která lze zavést na 32bitových implementacích firmwaru UEFI běžících na procesorech x86-64 , přičemž požadavek na předávání UEFI ze zaváděcího zavaděče UEFI je požadován. Předávací protokol UEFI deduplikuje inicializační kód UEFI mezi jádrem a zavaděči UEFI, takže inicializaci bude provádět pouze zaváděcí stoh UEFI jádra Linuxu .

Kompatibilita diskových zařízení

Viz také: GPT § Podpora operačních systémů a Protective MBR

Kromě standardního schématu diskových oddílů na PC, který používá hlavní spouštěcí záznam (MBR), UEFI pracuje také se schématem dělení tabulky GUID Partition Table (GPT), které neobsahuje mnoho omezení MBR. Uvolňují se zejména limity MBR na počet a velikost diskových oddílů (až čtyři primární oddíly na disk a až 2  TB (2 × 2 40 bajtů ) na disk). GPT konkrétně umožňuje maximální velikost disku a diskového oddílu 8  ZB (8 × 2 70 bajtů) .

Linux

Viz také: Systémový oddíl EFI § Linux

Podpora GPT v Linuxu je povolena zapnutím možnosti CONFIG_EFI_PARTITION(Podpora oddílů EFI GUID) během konfigurace jádra. Tato možnost umožňuje Linuxu rozpoznat a používat disky GPT poté, co firmware systému předá kontrolu nad systémem Linuxu.

Aby byla zajištěna zpětná kompatibilita, může Linux používat disky GPT v systémech založených na systému BIOS pro ukládání i zavádění dat, protože GRUB 2 i Linux podporují technologii GPT . Takové nastavení se obvykle označuje jako BIOS-GPT . Jelikož GPT obsahuje ochranný MBR, počítač se systémem BIOS lze spouštět z disku GPT pomocí zavaděče podporujícího GPT uloženého v oblasti kódu bootstrap ochranného MBR . V případě GRUB taková konfigurace vyžaduje spouštěcí oddíl BIOSu, aby GRUB vložil kód druhé fáze kvůli absenci mezery po MBR na discích s oddíly GPT (což je převzato tabulkou primárního záhlaví a tabulky primárních oddílů GPT ). Globálně jedinečný identifikátor (GUID) globálně jedinečného identifikátoru (GUID) tohoto schématu v GPT je obvykle 1  MB , je 21686148-6449-6E6F-744E-656564454649 a GRUB jej používá pouze v nastavení BIOS-GPT. Z pohledu GRUBu žádný takový typ oddílu neexistuje v případě rozdělení MBR. Tento oddíl není vyžadován, pokud je systém založen na UEFI, protože v takovém případě není nutné vkládání kódu druhého stupně.

Systémy UEFI mohou přistupovat k diskům GPT a spouštět je přímo z nich, což Linuxu umožňuje používat zaváděcí metody UEFI. Zavádění Linuxu z disků GPT na systémech UEFI zahrnuje vytvoření systémového oddílu EFI (ESP), který obsahuje aplikace UEFI, jako jsou zavaděče, jádra operačního systému a obslužný software. Takové nastavení se obvykle označuje jako UEFI-GPT , zatímco pro maximální kompatibilitu se doporučuje mít ESP alespoň 512 MB a musí být formátováno pomocí souborového systému FAT32.

Z důvodu zpětné kompatibility podporuje většina implementací UEFI také zavádění z disků s oddíly MBR prostřednictvím modulu Compatibility Support Module (CSM), který poskytuje starší kompatibilitu systému BIOS. V takovém případě je zavedení Linuxu na systémech UEFI stejné jako na starších systémech založených na systému BIOS.

Microsoft Windows

64bitové verze Windows Vista SP1 a novější a 32bitové verze Windows 8 , 8.1 a 10 lze zavést z disku GPT, který je větší než 2  TB .

Funkce

Služby

Příklad proměnných UEFI

EFI definuje dva typy služeb: bootovací služby a runtime služby . Bootovací služby jsou k dispozici pouze tehdy, když firmware vlastní platformu (tj. Před ExitBootServices()voláním), a zahrnují textové a grafické konzoly na různých zařízeních a sběrnicové, blokové a souborové služby. Služby runtime jsou stále přístupné, i když je operační systém spuštěn; zahrnují služby, jako je datum, čas a přístup NVRAM .

Služby Graphics Output Protocol (GOP)
Graphics Output Protocol (GOP) poskytuje runtime služby; viz také část Grafické funkce níže. Operační systém může během runtime režimu přímo zapisovat do framebufferu poskytovaného GOP.
Služby mapování paměti UEFI
Služby SMM
Služby ACPI
Služby SMBIOS
Variabilní služby
Proměnné UEFI poskytují způsob ukládání dat, zejména energeticky nezávislých dat. Některé proměnné UEFI jsou sdíleny mezi firmwarem platformy a operačními systémy. Prostory názvů proměnných jsou identifikovány identifikátory GUID a proměnné jsou páry klíč/hodnota. Proměnné UEFI lze například použít k uchování zpráv o selhání v NVRAM po havárii, kterou může operační systém načíst po restartu.
Časové služby
UEFI poskytuje časové služby. Časové služby zahrnují podporu pro časové pásmo a pole pro letní čas, které umožňují nastavení hodin reálného času hardwaru na místní čas nebo UTC. Na počítačích využívajících hodiny reálného času PC-AT musí být ve výchozím nastavení hardwarové hodiny nastaveny na místní čas, aby byla zajištěna kompatibilita se systémem Windows se systémem BIOS, pokud není použito nejnovější verze a není nastavena položka v registru systému Windows, která indikuje použití. UTC.

Aplikace

Interakce mezi správcem spouštění EFI a ovladači EFI

Kromě načítání operačního systému může UEFI spouštět aplikace UEFI , které se nacházejí jako soubory v systémovém oddílu EFI . Mohou být spuštěny z prostředí UEFI Shell, pomocí správce spouštění firmwaru nebo jiných aplikací UEFI. Aplikace UEFI lze vyvíjet a instalovat nezávisle na výrobcích původního zařízení (OEM).

Typ aplikace UEFI je zavaděč operačního systému, jako je GRUB , rEFInd , Gummiboot a Windows Boot Manager ; který načte některé soubory OS do paměti a provede je. Zavaděč OS může také poskytnout uživatelské rozhraní, které umožní spuštění výběru jiné aplikace UEFI. Nástroje jako UEFI Shell jsou také aplikacemi UEFI.

Protokoly

EFI definuje protokoly jako sadu softwarových rozhraní používaných pro komunikaci mezi dvěma binárními moduly. Všechny ovladače EFI musí poskytovat služby ostatním prostřednictvím protokolů. Protokoly EFI jsou podobné volání přerušení systému BIOS .

Ovladače zařízení

Kromě standardních ovladačů zařízení specifických pro architekturu instrukční sady EFI poskytuje ovladač zařízení nezávislý na ISA uložený v energeticky nezávislé paměti jako bajtový kód EFI nebo EBC . Systémový firmware má tlumočník pro obrazy EBC. V tomto smyslu je EBC analogický s otevřeným firmwarem , firmwarem nezávislým na ISA používaným mimo jiné v počítačích Apple Macintosh a Sun Microsystems SPARC na bázi PowerPC .

Některé ovladače EFI specifické pro architekturu (bez kódu EFI Byte) pro některé typy zařízení mohou mít rozhraní pro použití operačním systémem. To umožňuje operačnímu systému spoléhat se na EFI, že ovladače budou provádět základní grafické a síťové funkce před a v případě, že jsou načteny ovladače specifické pro operační systém.

V ostatních případech mohou být ovladači EFI ovladače souborového systému, které umožňují spouštění z jiných typů diskových svazků. Mezi příklady patří efify pro 37 souborových systémů (na základě kódu GRUB2 ), které používá Rufus pro řetězové načítání ESP NTFS.

Grafické funkce

Specifikace EFI 1.0 definovala protokol UGA (Universal Graphic Adapter) jako způsob podpory grafických funkcí. UEFI neobsahoval UGA a nahradil jej GOP (Graphics Output Protocol).

UEFI 2.1 definoval „Infrastrukturu lidského rozhraní“ (HII) pro správu vstupu uživatele, lokalizovaných řetězců, písem a formulářů (ve smyslu HTML ). Ty umožňují výrobcům původního zařízení (OEM) nebo nezávislým prodejcům systému BIOS (IBV) navrhovat grafická rozhraní pro konfiguraci před spuštěním.

Většina raných implementací firmwaru UEFI byla založena na konzole. Dnes je mnoho implementací firmwaru UEFI založeno na GUI.

Systémový oddíl EFI

Hlavní článek: EFI systémový oddíl

Systémový oddíl EFI, často zkráceně ESP, je oddíl zařízení pro ukládání dat, který se používá v počítačích dodržujících specifikaci UEFI. Přístup k firmwaru UEFI, když je počítač zapnutý, ukládá aplikace UEFI a soubory, které tyto aplikace potřebují ke spuštění, včetně zavaděčů operačního systému . Mezi podporovaná schémata tabulek oddílů patří MBR a GPT , stejně jako svazky El Torito na optických discích. Pro použití na ESP definuje UEFI konkrétní verzi systému souborů FAT , která je udržována jako součást specifikace UEFI a nezávisle na původní specifikaci FAT, zahrnující souborové systémy FAT32 , FAT16 a FAT12 . ESP také poskytuje místo pro zaváděcí sektor jako součást zpětné kompatibility systému BIOS.

Bootování

Zavádění UEFI

Na rozdíl od staršího systému BIOS systému BIOS se UEFI nespoléhá na zaváděcí sektory a místo toho definuje správce spouštění jako součást specifikace UEFI. Když je počítač zapnutý, správce spouštění zkontroluje konfiguraci spouštění a na základě jejích nastavení poté provede zadaný zavaděč operačního systému nebo jádro operačního systému (obvykle zavaděč). Konfigurace spouštění je definována proměnnými uloženými v NVRAM , včetně proměnných, které označují cesty systému souborů k zavaděčům OS nebo jádrům OS.

Zavaděče OS lze automaticky detekovat pomocí UEFI, což umožňuje snadné zavádění z vyměnitelných zařízení, jako jsou USB flash disky . Tato automatická detekce se spoléhá na standardizované cesty souborů k zavaděči operačního systému, přičemž cesta se liší v závislosti na architektuře počítače . Formát cesty k souboru je definován jako <EFI_SYSTEM_PARTITION> \ EFI \ BOOT \ BOOT <MACHINE_TYPE_SHORT_NAME> .EFI ; například cesta k souboru k zavaděči OS v systému x86-64 je \ efi \ boot \ bootx64.efi a \ efi \ boot \ bootaa64.efi na architektuře ARM64.

Proces spouštění

Zavádění systémů UEFI z disků rozdělených na GPT se běžně nazývá bootování UEFI-GPT . Navzdory skutečnosti, že specifikace UEFI vyžaduje plnou podporu tabulek oddílů GPT, některé implementace firmwaru UEFI okamžitě přejdou na bootování CSM založené na systému BIOS v závislosti na typu tabulky oddílů spouštěcí diskety, což účinně brání spuštění UEFI z EFI System Partition na discích s oddíly MBR. Takové zaváděcí schéma se běžně nazývá UEFI-MBR .

Je také běžné, že správce spouštění má textové uživatelské rozhraní, takže si uživatel může vybrat požadovaný OS (nebo nástroj pro nastavení) ze seznamu dostupných možností spouštění.

Zavádění CSM

Aby byla zajištěna zpětná kompatibilita, většina implementací firmwaru UEFI na počítačích třídy PC také podporuje spouštění ve starším režimu BIOS z disků s oddíly MBR prostřednictvím modulu Compatibility Support Module (CSM), který poskytuje starší kompatibilitu systému BIOS. V tomto scénáři se spouštění provádí stejným způsobem jako na starších systémech založených na systému BIOS ignorováním tabulky oddílů a spoléháním na obsah spouštěcího sektoru .

Zavádění systému BIOS z disků s oddíly MBR se běžně nazývá BIOS-MBR , bez ohledu na to, zda je prováděno v systémech založených na systému UEFI nebo starších systémech BIOS. Kromě toho je také možné zavádění starších systémů založených na systému BIOS z disků GPT a takové zaváděcí schéma se běžně nazývá BIOS-GPT .

Support Module Compatibility umožňuje starší operační systémy a některé starší volba ROM , které nepodporují UEFI, které mají být nadále používány. Poskytuje také požadovanou starší funkci System Management Mode (SMM), nazývanou CompatibilitySmm , jako doplněk k funkcím poskytovaným UEFI SMM. Příkladem takové starší funkce SMM je poskytování starší podpory USB pro klávesnici a myš pomocí emulace jejich klasických protějšků PS/2 .

V listopadu 2017 společnost Intel oznámila, že do roku 2020 plánuje postupně ukončit podporu CSM.

Zavádění sítě

Specifikace UEFI obsahuje podporu pro zavádění přes síť prostřednictvím prostředí Preboot eXecution Environment (PXE). Mezi síťové protokoly pro spouštění PXE patří Internet Protocol ( IPv4 a IPv6 ), User Datagram Protocol (UDP), Dynamic Host Configuration Protocol (DHCP), Trivial File Transfer Protocol (TFTP) a iSCSI .

Obrazy OS lze vzdáleně ukládat do sítí úložišť (SAN), s podporovanými protokoly pro přístup k sítím SAN pomocí rozhraní Internet Small Computer System Interface (iSCSI) a Fibre Channel over Ethernet (FCoE).

Verze 2.5 specifikace UEFI přidává podporu pro přístup ke spouštěcím bitovým kopiím přes protokol HTTP .

Bezpečné spuštění

Viz také: Kritika Secure Boot
Příklad aktivního zabezpečeného spouštění detekovaného správcem spouštění rEFInd

Specifikace UEFI 2.3.1 Errata C (nebo vyšší) definuje protokol známý jako Secure Boot , který může zajistit proces spouštění tím, že zabrání načítání ovladačů UEFI nebo zavaděčů OS, které nejsou podepsány přijatelným digitálním podpisem . Mechanické podrobnosti o tom, jak přesně mají být tyto ovladače podepsány, nejsou specifikovány. Když je zapnuto zabezpečené spouštění, je původně uvedeno do režimu „nastavení“, který umožňuje zapsat do firmwaru veřejný klíč známý jako „klíč platformy“ (PK). Jakmile je klíč zapsán, Secure Boot přejde do režimu „Uživatel“, kde firmware může načíst pouze ovladače UEFI a zavaděče OS podepsané klíčem platformy. Do databáze uložené v paměti lze přidat další „klíče pro výměnu klíčů“ (KEK), aby bylo možné používat další certifikáty, ale stále musí mít připojení k soukromé části klíče platformy. Zabezpečené spouštění lze také umístit do režimu „Vlastní“, kde lze do systému přidat další veřejné klíče, které neodpovídají soukromému klíči.

Secure Boot je podporován systémy Windows 8 a 8.1 , Windows Server 2012 a 2012 R2, Windows 10 , Windows Server 2016 , 2019 a 2022 a Windows 11 , VMware vSphere 6.5 a řadou distribucí Linuxu včetně Fedory (od verze 18), openSUSE (od verze 12.3), RHEL (od verze 7), CentOS (od verze 7), Debian (od verze 10) a Ubuntu (od verze 12.04.2). V lednu 2017 je podpora FreeBSD ve fázi plánování.

Shell UEFI

Příklad relace UEFI Shell 2.2

UEFI poskytuje prostředí prostředí , které lze použít ke spouštění dalších aplikací UEFI, včetně zavaděčů UEFI . Kromě toho lze příkazy dostupné v prostředí UEFI použít k získání různých dalších informací o systému nebo firmwaru, včetně získání mapy paměti ( memmap), úpravy proměnných správce spouštění ( bcfg), spouštění programů pro dělení oddílů ( diskpart), načítání ovladačů UEFI, a úpravy textových souborů ( edit).

Zdrojový kód k UEFI pláště lze stáhnout ze společnosti Intel ‚s TianoCore projektu UDK / EDK2. K dispozici je také předem připravený ShellBinPkg. Shell v2 funguje nejlépe v systémech UEFI 2.3+ a je v těchto systémech doporučován nad Shell v1. Shell v1 by měl fungovat ve všech systémech UEFI.

Metody používané ke spuštění shellu UEFI závisí na výrobci a modelu základní desky systému . Některé z nich již poskytují přímou možnost v nastavení firmwaru pro spuštění, např. Kompilovaná verze shellu x86-64 musí být k dispozici jako <EFI_SYSTEM_PARTITION>/SHELLX64.EFI. Některé další systémy mají již integrovaný shell UEFI, který lze spustit vhodnými kombinacemi stisknutí kláves. U ostatních systémů je řešením buď vytvoření vhodné jednotky USB flash, nebo ruční ( bcfg) přidání zaváděcí možnosti spojené se zkompilovanou verzí shellu.

Příkazy

Následuje seznam příkazů podporovaných EFI shellem.

Rozšíření

Rozšíření UEFI lze načíst prakticky z libovolného energeticky nezávislého paměťového zařízení připojeného k počítači. Například výrobce původního zařízení (OEM) může distribuovat systémy se systémovým oddílem EFI na pevném disku, což by přidalo další funkce ke standardnímu firmwaru UEFI uloženému v paměti ROM základní desky .

Kapsle UEFI

UEFI Capsule definuje moderní a bezpečné rozhraní pro aktualizaci firmwaru. Windows 8 , Windows 8.1 , Windows 10 a Fwupd pro Linux podporují kapsli UEFI.

Hardware

Stejně jako BIOS , UEFI inicializuje a testuje hardwarové součásti systému (např. Trénink paměti, školení propojení PCIe, trénink propojení USB) a poté načte zavaděč z velkokapacitního paměťového zařízení nebo ze spouštění ze sítě . V systémech x86 je firmware UEFI obvykle uložen v čipu NOR flash základní desky.

Třídy UEFI

Počítače UEFI mohou mít jednu z následujících „tříd“, které byly použity k usnadnění přechodu na UEFI. Intel ukončil Legacy BIOS v roce 2020.

  • Třída 0: Starší BIOS
  • Třída 1: UEFI v režimu pouze CSM (tj. Bez bootování UEFI)
  • Třída 2: UEFI s CSM
  • Třída 3: UEFI bez CSM
  • Třída 3+: UEFI s povoleným zabezpečeným spuštěním

Fáze spouštění

SEC - fáze zabezpečení

Toto je první fáze spouštění UEFI, ale může tomu předcházet binární kód specifický pro platformu. (např. Intel ME , AMD PSP , mikrokód CPU ). Skládá se z minimálního kódu napsaného v jazyce sestavení pro konkrétní architekturu. Inicializuje dočasnou paměť (často mezipaměť CPU jako RAM) a slouží jako kořen důvěryhodnosti softwaru systému s možností ověření PEI před předáním.

PEI - Inicializace před EFI

Druhá fáze spouštění UEFI se skládá z dispečera závislého na závislosti, který načítá a spouští moduly PEI (PEIM) pro zpracování počátečních úloh inicializace hardwaru, jako jsou operace inicializace hlavní paměti a obnovy firmwaru. Kromě toho je zodpovědný za zjišťování aktuálního zaváděcího režimu a za zpracování mnoha operací ACPI S0ix/ACPI S3. V případě obnovení ACPI S0ix/ACPI S3 je zodpovědný za obnovení mnoha hardwarových registrů do stavu před spánkem. PEI také používá mezipaměť CPU jako RAM.

DXE - prostředí spouštění ovladačů

Tato fáze se skládá z modulů C a dispečera závislého na závislosti. Protože je nyní k dispozici hlavní paměť, jsou CPU, čipová sada, základní deska a periferie inicializovány v DXE a BDS.

BDS - Vyberte zaváděcí zařízení

BDS je součástí DXE. V této fázi se inicializují I/O zařízení a zaváděcí zařízení, podle konfigurace systému se spouští ovladače UEFI nebo volitelné paměti ROM zařízení PCI a zpracovávají se možnosti spouštění.

TSL - Přechodné zatížení systému

Toto je fáze mezi výběrem zaváděcího zařízení a předáním OS. V tomto okamžiku lze vstoupit do shellu UEFI nebo spustit aplikaci UEFI, jako je zavaděč OS.

RT - Runtime

UEFI předá operačnímu systému (OS) po spuštění ExitBootServices () . Operační systém kompatibilní s UEFI je nyní zodpovědný za ukončení zaváděcích služeb, které způsobí, že firmware uvolní veškerý již nepotřebný kód a data, takže zůstane pouze kód/data runtime služeb, např. SMM a ACPI . Typický moderní operační systém bude pro ovládání hardwarových zařízení upřednostňovat používání vlastních programů (například ovladačů jádra ).

Když je použit starší operační systém, CSM toto volání zpracuje a zajistí, aby byl systém kompatibilní se starším očekáváním systému BIOS.

Implementace a adopce

Intel EFI

Hlavní článek: TianoCore EDK II
InsydeH2O, implementace UEFI

Implementace EFI společností Intel je Intel Platform Innovation Framework s kódovým označením Tiano . Tiano běží na procesorech Intel XScale , Itanium , x86-32 a x86-64 a je proprietárním softwarem, i když část kódu byla vydána pod licencí BSD nebo Eclipse Public License (EPL) jako TianoCore . TianoCore lze použít jako užitečné zatížení pro coreboot .

Implementace UEFI od Phoenix Technologies je označována jako SecureCore Technology (SCT). American Megatrends nabízí vlastní implementaci firmwaru UEFI známou jako Aptio, zatímco Insyde Software nabízí InsydeH2O.

V prosinci 2018 společnost Microsoft vydala open source verzi implementace UEFI založené na TianoCore EDK2 z řady Surface , Project Mu .

Das U-Boot

Implementace API UEFI byla zavedena do Universal Boot Loader ( Das U-Boot ) v roce 2017. Na architektuře ARMv8 používají linuxové distribuce implementaci U-Boot UEFI ve spojení s GNU GRUB pro bootování (např. SUSE Linux ), to samé platí pro OpenBSD. Pro bootování z iSCSI lze iPXE použít jako aplikaci UEFI načtenou U-Boot.

Platformy využívající EFI/UEFI

První pracovní stanice a servery společnosti Intel s procesorem Itanium , vydané v roce 2000, implementovaly EFI 1.02.

První systémy Itanium 2 společnosti Hewlett-Packard , vydané v roce 2002, implementovaly EFI 1.10; dokázali zavést Windows , Linux , FreeBSD a HP-UX ; OpenVMS přidal schopnost UEFI v červnu 2003.

V lednu 2006 dodala společnost Apple Inc. své první počítače Macintosh s procesorem Intel . Tyto systémy používaly EFI místo Open Firmware , který byl použit na jeho předchozích systémech založených na PowerPC. Dne 5. dubna 2006 společnost Apple poprvé vydala Boot Camp , který produkuje disk s ovladači systému Windows a nedestruktivní nástroj pro vytváření oddílů, který umožňuje instalaci systému Windows XP nebo Vista bez nutnosti přeinstalování systému Mac OS X. Byla také vydána aktualizace firmwaru, která přidala Kompatibilita systému BIOS s implementací EFI. Následující modely Macintosh byly dodány s novějším firmwarem.

V průběhu roku 2005 bylo s implementací UEFI společnosti Intel dodáno více než jeden milion systémů Intel. Nové mobilní, stolní a serverové produkty využívající implementaci UEFI od společnosti Intel se začaly dodávat v roce 2006. Například desky, které používají řadu čipových sad Intel 945, používají implementaci firmwaru UEFI společnosti Intel.

Od roku 2005 je EFI implementován také na architekturách jiných než PC, jako jsou vestavěné systémy založené na jádrech XScale .

EDK (EFI Developer Kit) obsahuje cíl NT32, který umožňuje firmwaru EFI a aplikacím EFI běžet v aplikaci Windows . EDK NT32 však nepovoluje žádný přímý přístup k hardwaru. To znamená, že na cíli EDK NT32 lze spustit pouze podmnožinu aplikace EFI a ovladačů.

V roce 2008 přijalo UEFI více systémů x86-64. Zatímco mnoho z těchto systémů stále umožňuje spouštění pouze operačních systémů založených na systému BIOS prostřednictvím modulu Compatibility Support Module (CSM) (tedy aby se uživateli nezdálo, že je založen na UEFI), jiné systémy začaly umožňovat spouštění operačních systémů založených na UEFI. Například server IBM x3450, základní desky MSI s ClickBIOS, notebooky HP EliteBook.

V roce 2009 dodala společnost IBM stroje System x (x3550 M2, x3650 M2, iDataPlex dx360 M2) a BladeCenter HS22 s funkcí UEFI. Společnost Dell dodala servery PowerEdge T610, R610, R710, M610 a M710 s funkcí UEFI. Více komerčně dostupných systémů je uvedeno v dokumentu white paper UEFI.

V roce 2011 uvedli hlavní prodejci (například ASRock , Asus , Gigabyte a MSI ) na trh několik základních desek orientovaných na spotřebitele s využitím čipové sady Intel 6 LGA 1155 a čipové sady AMD 9 Series AM3+ s UEFI.

S vydáním systému Windows 8 v říjnu 2012 požadavky na certifikaci společnosti Microsoft nyní vyžadují, aby počítače obsahovaly firmware, který implementuje specifikaci UEFI. Kromě toho, pokud počítač podporuje funkci „ Connected Standby “ systému Windows 8 (která umožňuje zařízením mít správu napájení srovnatelnou se smartphony , s téměř okamžitým návratem z pohotovostního režimu), pak firmware nesmí obsahovat modul podpory kompatibility ( CSM). Systémy, které podporují Connected Standby, proto nemohou spouštět starší operační systémy BIOS.

V říjnu 2017 společnost Intel oznámila, že do roku 2020 odstraní ze všech svých produktů starší podporu systému BIOS pro počítače ve prospěch třídy UEFI 3.

Operační systémy

Operační systém, který lze spustit z (U) EFI, se nazývá (U) EFI-aware operační systém, definovaný (U) EFI specifikací. Zde výraz zavedený z (U) EFI znamená přímé zavedení systému pomocí zavaděče operačního systému (U) EFI uloženého na libovolném úložném zařízení. Výchozí umístění pro zavaděč operačního systému, je <EFI_SYSTEM_PARTITION>/BOOT/BOOT<MACHINE_TYPE_SHORT_NAME>.EFI-li krátký název typu stroje může být IA32, X64, IA64, ARMnebo AA64. Někteří prodejci operačních systémů mohou mít vlastní zavaděče. Mohou také změnit výchozí umístění spouštění.

  • Linuxové jádro byl schopen použít EFI při bootu Od počátku roku 2000, s použitím elilo EFI zavaděč nebo nověji EFI verze GRUB . Grub+Linux také podporuje zavádění z tabulky oddílů GUID bez UEFI. Distribuce Ubuntu přidala podporu pro UEFI Secure Boot od verze 12.10. Kromě toho lze jádro Linuxu kompilovat s možností běžet jako bootloader EFI samostatně pomocí funkce EFI bootstub.
  • HP-UX používá (U) EFI jako svůj zaváděcí mechanismus v systémech IA-64 od roku 2002.
  • OpenVMS používá EFI na IA-64 od jeho prvního vydání hodnocení v prosinci 2003 a pro produkční vydání od ledna 2005. Port x86-64 OpenVMS také používá UEFI ke spuštění operačního systému.
  • Společnost Apple používá EFI pro řadu počítačů Mac s procesorem Intel . Mac OS X v10.4 Tiger a Mac OS X v10.5 Leopard implementují EFI v1.10 ve 32bitovém režimu i na novějších 64bitových CPU, ale plná podpora přišla s OS X v10.8 Mountain Lion .
  • Na Itanium verze systému Windows 2000 (Advanced Server Limited Edition a Datacenter Server limitovaná edice) implementována EFI 1,10 v roce 2002. MS Windows Server 2003 pro IA-64 , MS Windows XP 64-bit Edition a Windows 2000 Advanced Server Limited Edition, z nichž všechny jsou pro rodinu procesorů Intel Itanium implementují EFI, což je požadavek platformy prostřednictvím specifikace DIG64 .
  • Microsoft představil UEFI pro x64 operační systémy Windows s Windows Vista SP1 a Windows Server 2008, podporován je však pouze UGA (Universal Graphic Adapter) 1.1 nebo Legacy BIOS INT 10h ; Graphics Output Protocol (GOP) není podporován. Počítače se 64bitovými verzemi Windows Vista SP1 , Windows Vista SP2 , Windows 7 , Windows Server 2008 a Windows Server 2008 R2 jsou proto kompatibilní s třídou UEFI 2. 32bitové UEFI původně nebylo podporováno, protože prodejci neměli žádný zájem při produkci nativního 32bitového firmwaru UEFI kvůli hlavnímu stavu 64bitových počítačů . Windows 8 konečně představil další optimalizace pro systémy UEFI, včetně podpory Graphics Output Protocol (GOP), rychlejšího spouštění, 32bitové podpory UEFI a podpory Secure Boot. Microsoft začal požadovat, aby UEFI provozovalo Windows s Windows 11 .
  • Dne 5. března 2013 nadace FreeBSD udělila grant vývojáři, který chce přidat podporu UEFI do jádra a bootloaderu FreeBSD . Změny byly původně uloženy v diskrétní větvi zdrojového kódu FreeBSD, ale byly sloučeny do zdroje hlavní řady 4. dubna 2014 (revize 264095); změny zahrnují také podporu v instalačním programu. Podpora spouštění UEFI pro amd64 se poprvé objevila ve FreeBSD 10.1 a pro arm64 ve FreeBSD 11.0.
  • Oracle Solaris 11.1 a novější podporují bootování UEFI pro systémy x86 s firmwarem UEFI verze 2.1 nebo novější. GRUB 2 se používá jako zavaděč na x86.
  • OpenBSD 5.9 představil podporu spouštění UEFI pro 64bitové systémy x86 pomocí vlastního vlastního zavaděče, OpenBSD 6.0 tuto podporu rozšířil o ARMv7.

Použití UEFI s virtualizací

  • Virtuální počítače HP Integrity poskytují spouštění UEFI na serverech HP Integrity. Poskytuje také virtualizované prostředí UEFI pro hostující operační systémy podporující UEFI.
  • Intel je hostitelem projektu Open Virtual Machine Firmware na SourceForge.
  • Software VMware Fusion 3 pro Mac OS X může spouštět virtuální stroje serveru Mac OS X pomocí UEFI.
  • Pracovní stanice VMware před verzí 11 neoficiálně podporuje UEFI, ale je ručně povolena úpravou souboru .vmx. VMware Workstation verze 11 a vyšší podporuje UEFI, bez ohledu na to, zda je fyzický hostitelský systém založený na UEFI. VMware Workstation 14 (a tedy Fusion 10) přidává podporu pro funkci Secure Boot UEFI.
  • VSphere ESXi 5.0 hypervisor oficiálně podporovat UEFI. Verze 6.5 přidává podporu pro Secure Boot.
  • Program VirtualBox implementoval UEFI od verze 3.1, ale je omezen na operační systémy Unix/Linux a některé verze Windows (nefunguje s Windows Vista x64 a Windows 7 x64).
  • QEMU / KVM lze použít s firmwarem Open Virtual Machine Firmware (OVMF) poskytovaným společností TianoCore .
  • Hypervisor VMware ESXi verze 5, součást VMware vSphere, podporuje virtualizované rozhraní UEFI jako alternativu ke staršímu systému BIOS systému BIOS ve virtuálním počítači.
  • Druhá generace virtuálního stroje Microsoft Hyper-V podporuje virtualizované UEFI.
  • Stíněné virtuální počítače Google Cloud Platform podporují virtualizované rozhraní UEFI, které umožňuje zabezpečené spouštění.

Vývoj aplikací

EDK2 Application Development Kit (EADK) umožňuje používat standardní funkce C knihovny v aplikacích UEFI. EADK lze volně stáhnout z projektu Intel TianoCore UDK / EDK2 SourceForge . Jako příklad je port tlumočníka Pythonu zpřístupněn jako aplikace UEFI pomocí EADK. Vývoj se od UDK2015 přesunul na GitHub.

Minimalistický C program „ ahoj, svět “ napsaný pomocí EADK vypadá podobně jako jeho obvyklý protějšek v jazyce C : 

#include <Uefi.h>
#include <Library/UefiLib.h>
#include <Library/ShellCEntryLib.h>

EFI_STATUS EFIAPI ShellAppMain(IN UINTN Argc, IN CHAR16 **Argv)
{
    Print(L"hello, world\n");
    return EFI_SUCCESS;
}

Kritika

Proti UEFI protestovala řada aktivistů za digitální práva. Ronald G. Minnich , spoluautor coreboot , a Cory Doctorow , aktivista digitálních práv, kritizovali UEFI jako pokus odstranit schopnost uživatele skutečně ovládat počítač. Neřeší dlouhodobé problémy systému BIOS vyžadující dva různé ovladače-jeden pro firmware a jeden pro operační systém-pro většinu hardwaru.

Open-source projekt TianoCore také poskytuje rozhraní UEFI. TianoCore postrádá specializované ovladače, které inicializují funkce čipové sady, které místo toho poskytuje coreboot , z nichž TianoCore je jednou z mnoha možností užitečného zatížení. Vývoj corebootu vyžaduje spolupráci výrobců čipových sad, aby poskytli specifikace potřebné k vývoji inicializačních ovladačů.

Bezpečné spuštění

Viz také: Windows 8 § Recepce
Příklady vlastních veřejných klíčů Secure Boot
MokManager, součást bootloaderu Shim

V roce 2011 společnost Microsoft oznámila, že počítače certifikované pro provoz operačního systému Windows 8 musí být dodávány s zaregistrovaným veřejným klíčem společnosti Microsoft a povoleným zabezpečeným spuštěním. Po tomto oznámení byla společnost kritiky a obhájci svobodného softwaru/open source (včetně Free Software Foundation ) obviněna ze snahy použít funkci Secure Boot UEFI k zabránění nebo úplnému zabránění instalace alternativních operačních systémů, jako je Linux . Microsoft popřel, že by požadavek na Secure Boot měl sloužit jako forma lock-in , a vyjasnil své požadavky prohlášením, že systémy založené na x86 certifikované pro Windows 8 musí umožnit Secure Boot vstoupit do vlastního režimu nebo být deaktivovány, ale ne na systémech pomocí architektury ARM . Systém Windows 10 umožňuje výrobcům OEM rozhodnout, zda lze zabezpečené spouštění spravovat uživateli jejich systémů x86.

Jiní vývojáři vyjádřili obavy ohledně právních a praktických problémů s implementací podpory pro Secure Boot v systémech Linux obecně. Bývalý vývojář Red Hat Matthew Garrett poznamenal, že podmínky v GNU General Public License verze 3 mohou bránit v používání GNU GRand Unified Bootloader, aniž by vývojář distribuce odhalil soukromý klíč ( Free Software Foundation však od té doby vyjasnila své postavení a ujistila se, že odpovědnost za zpřístupnění klíčů nesl výrobce hardwaru) a pro pokročilé uživatele by bylo také obtížné vytvářet vlastní jádra, která by mohla fungovat s povoleným zabezpečeným spuštěním, aniž by je sám podepisoval. Jiní vývojáři navrhli, že by mohly být poskytnuty podepsané verze Linuxu s jiným klíčem, ale poznamenali, že by bylo obtížné přesvědčit výrobce OEM, aby dodali své počítače s požadovaným klíčem vedle klíče Microsoft.

Několik hlavních distribucí Linuxu vyvinulo různé implementace pro Secure Boot. Sám Garrett vyvinul minimální bootloader známý jako shim, což je předkompilovaný, podepsaný bootloader, který uživateli umožňuje individuálně důvěřovat klíčům poskytovaným distribucemi Linuxu. Ubuntu 12.10 používá starší verzi shim předem nakonfigurovanou pro použití s vlastním klíčem Canonical, který ověřuje pouze bootloader a umožňuje načtení nepodepsaných jader; vývojáři se domnívají, že praxe podepisování pouze zavaděče je proveditelnější, protože důvěryhodné jádro účinně zajišťuje pouze uživatelský prostor , a nikoli stav před spuštěním, pro který je Secure Boot určen k přidání ochrany. To také umožňuje uživatelům vytvářet vlastní jádra a používat také vlastní moduly jádra bez nutnosti překonfigurovat systém. Společnost Canonical také udržuje svůj vlastní soukromý klíč k podepisování instalací Ubuntu předinstalovaných na certifikovaných počítačích OEM, na kterých běží operační systém, a také plánuje prosadit požadavek na Secure Boot-vyžadující jak Canonical klíč, tak i klíč Microsoft (z důvodu kompatibility) ), které mají být zahrnuty v jejich firmwaru. Fedora také používá shim, ale vyžaduje, aby bylo podepsáno jak jádro, tak jeho moduly.

Bylo sporné, zda musí být podepsáno také jádro operačního systému a jeho moduly; i když to specifikace UEFI nevyžadují, společnost Microsoft prohlásila, že jejich smluvní požadavky ano, a že si vyhrazuje právo zrušit všechny certifikáty použité k podpisu kódu, které lze použít ke snížení zabezpečení systému. V systému Windows je povolen pouze ovladač jádra WHQL, pokud je povoleno zabezpečené spouštění. V únoru 2013 se další vývojář Red Hat pokusil odeslat do jádra Linux opravu, která by mu umožnila analyzovat podepisování autentických kódů společnosti Microsoft pomocí hlavního klíče X.509 vloženého do souborů PE podepsaných společností Microsoft. Tento návrh však kritizoval tvůrce Linuxu Linus Torvalds , který zaútočil na Red Hat za podporu kontroly nad infrastrukturou Secure Boot ze strany Microsoftu.

Dne 26. března 2013 podala španělská skupina pro bezplatný vývoj softwaru Hispalinux formální stížnost na Evropskou komisi a tvrdila, že požadavky Microsoft Secure Boot na systémy OEM byly „obstrukční“ a narušující hospodářskou soutěž .

Na konferenci Black Hat v srpnu 2013 skupina bezpečnostních výzkumníků představila sérii vykořisťování konkrétních dodavatelských implementací UEFI, které by bylo možné využít k využití Secure Boot.

V srpnu 2016 bylo oznámeno, že dva bezpečnostní výzkumníci našli bezpečnostní klíč „zlatý klíč“, který Microsoft používá při podepisování operačních systémů. Technicky nebyl odhalen žádný klíč, ale zneužitelný binární soubor podepsaný klíčem byl. To umožňuje libovolnému softwaru běžet, jako by byl skutečně podepsán společností Microsoft, a odhaluje možnost útoků rootkit a bootkit . To také znemožňuje opravu chyby, protože jakoukoli opravu lze nahradit (downgradovat) pomocí (podepsaného) zneužitelného binárního souboru. Společnost Microsoft odpověděla prohlášením, že chyba zabezpečení existuje pouze v architektuře ARM a zařízeních Windows RT , a vydala dvě opravy; Záplaty však (a nemohou) tuto chybu zabezpečení neodstranit, což by vyžadovalo opravu klíčů ve firmwaru koncového uživatele.

Mnoho distribucí Linuxu nyní podporuje UEFI Secure Boot, například RHEL (RHEL 7 a novější), CentOS (CentOS 7 a novější), Ubuntu , Fedora , Debian (Debian 10 a novější), OpenSUSE , SUSE Linux .

Problémy s firmwarem

Zvýšená důležitost firmwaru UEFI v zařízeních také vedla k řadě technických problémů, které jsou přičítány jejich příslušným implementacím.

Po vydání systému Windows 8 na konci roku 2012 bylo zjištěno, že některé modely počítačů Lenovo s funkcí Secure Boot mají firmware napevno zakódovaný tak, aby umožňoval načítání pouze spustitelných souborů s názvem „ Windows Boot Manager “ nebo „ Red Hat Enterprise Linux “, bez ohledu na jakékoli jiné nastavení. K dalším problémům došlo u několika modelů notebooků Toshiba s funkcí Secure Boot, kterým chyběly určité certifikáty potřebné pro správnou funkci.

V lednu 2013 byla zveřejněna chyba obklopující implementaci UEFI na některých přenosných počítačích Samsung , což způsobilo jejich zděšení po instalaci distribuce Linuxu v režimu UEFI. Zatímco zpočátku byly obviňovány potenciální konflikty s modulem jádra určeným pro přístup k systémovým funkcím na přenosných počítačích Samsung (což také vedlo správce jádra k deaktivaci modulu v systémech UEFI jako bezpečnostní opatření), Matthew Garrett zjistil, že chyba byla skutečně spuštěna uložením příliš velkého počtu UEFI proměnné do paměti a že chyba může být za určitých podmínek spuštěna i pod Windows. Na závěr určil, že modul poškozujícího jádra způsobil, že do firmwaru byly zapsány výpisy zpráv jádra, čímž byla spuštěna chyba.

Viz také

Poznámky

Reference

Další čtení

externí odkazy