Üdvözlünk a Pcsegéd-nél

Mi azon dolgozunk, hogy meg könnyítsük a ti dolgotokat azért, hogy ne kelljen elvinni szervízbe.

intro-pic.png

Unified Extensible Firmware Interface (UEFI)

uefi.png Ez a cikk csak azért készült el mert nem találtam magyar nyelven értelmes UEFI bemutatót és gondoltam csinálok egyet.
Az Unified Extensible Firmware Interface ( UEFI ) egy olyan specifikáció, amely meghatározza a szoftver interfészt az operációs rendszer és a platform firmware között.
Az UEFI kicseréli az összes IBM PC-kompatibilis személyi számítógépről eredetileg jelen lévő Basic Input / Output System ( BIOS ) firmware-interfészt, a legtöbb UEFI firmware-implementációval, amelyek a BIOS szolgáltatások korábbi támogatását nyújtják.
Az UEFI képes támogatni a távoli diagnosztikát és a számítógépek javítását, még akkor sem, ha nincs telepítve az operációs rendszer.
Az Intel kifejlesztette az eredeti Extensible Firmware Interface ( EFI ) specifikációt. Az EFI gyakorlati és adatformátumainak egy része a Microsoft Windows operációs rendszereit tükrözi.
2005-ben az UEFI elbocsátotta az EFI 1.10-et (az EFI végleges kiadása). Az Unified EFI Forum az iparági szervezet, amely kezeli az UEFI specifikációt.

UEFI története.


Az EFI eredeti motivációja az első Intel-HP Itanium rendszerek korai fejlesztése során jött az 1990-es évek közepén. A BIOS- korlátozások (például a 16 bites processzor mód , 1 MB címezhető terület és PC AT hardver) túlságosan megszorítóvá vált az Itanium által megcélzott nagyobb kiszolgálóplatformokhoz. Az aggodalmak kezelése 1998-ban kezdődött, és eredetileg az Intel Boot kezdeményezésnek nevezték. Ezt később átnevezték az Extensible Firmware Interface (EFI) kifejezésre. 2005 júliusában az Intel megszüntette az EFI specifikáció fejlesztését az 1.10 verzióban, és hozzájárult az Unified EFI Forumhoz , amely a specifikációt Unified Extensible Firmware Interface (UEFI) néven fejlesztette ki. Az eredeti EFI specifikáció továbbra is az Intel tulajdonában van, amely kizárólag EFI-alapú termékekre vonatkozik, azonban az UEFI specifikáció az UEFI Forum tulajdonában van. Az UEFI specifikáció 2.1-es verziója 2007. január 7-én jelent meg. Hozzáadta a kriptográfiát , a hálózati hitelesítést és a felhasználói interfész- architektúrát (Human Interface Infrastructure in UEFI). A legutóbbi UEFI-specifikáció 2.7-es verzióját 2017. májusában hagyta jóvá.

Előnyei a BIOS-hoz képest.


Az EFI-specifikáció által definiált interfész olyan adatbázist tartalmaz, amely tartalmaz platforminformációkat, valamint az OS betöltő és az operációs rendszer számára elérhető rendszerindítási és futási szolgáltatásokat.
Az UEFI firmware számos technikai előnyt nyújt a hagyományos BIOS rendszerhez képest:
Nagy lemezek. (2 TB feletti)
CPU-független architektúra.
CPU-független meghajtók.
Rugalmas előre OS környezet, beleértve a hálózati képességet.
Moduláris kialakítás.
Visszafelé és előre kompatibilitás.

UEFI Kompatibilitás


Processzor kompatibilitás


A 2.5-ös verziótól kezdve a processzor kötések Itanium, x86, x86-64, ARM (AArch32) és ARM64 ( AArch64) esetén léteznek.
Csak kis endian processzorok támogathatók.
Nem hivatalos UEFI támogatás fejlesztés alatt POWERPC64 végrehajtásával TianoCore tetején OPAL, a OpenPower absztrakciós réteg, futó kis-végű módot.
Hasonló projektek léteznek a MIPS és a RISC-V esetében.Az UEFI 2.7-től a RISC-V processzorkötéseket hivatalosan 32, 64 és 128 bites módokhoz hozták létre.
A szabványos PC BIOS 16 bites processzor módra és 1 MB címezhető memóriaterületre korlátozódik, ami az IBM 5150 alapú tervezésből adódik, amely egy 16 bites Intel 8088 processzort használt.
Összehasonlításképpen, az UEFI környezetben a processzor üzemmód lehet akár 32 bites ( x86-32 , AArch32) vagy 64 bites ( x86-64 , Itanium és AArch64).
A 64 bites UEFI firmware-implementációk támogatják a hosszú módot , amely lehetővé teszi, hogy az előtelepítési környezetben lévő alkalmazások 64 bites címzést használjanak, hogy közvetlen hozzáférést biztosítsanak a gép összes memóriájához.
Az UEFI megköveteli, hogy a firmware és az operációs rendszer betöltője (vagy rendszermagja) méretkorrekcióban legyen; Például egy 64 bites UEFI firmware-implementáció csak egy 64 bites operációs rendszer (OS) betöltő vagy rendszermag betöltésére képes.
Miután a rendszer átállt a "Boot Services" -ról a "Runtime Services" -re, az operációs rendszer rendszermagja átveszi.
Ezen a ponton a rendszermag megváltoztathatja a processzor módokat, ha ez a vágy, de ez a raszter használatát használja a futásidejű szolgáltatásoknak (hacsak a rendszermag vissza nem tér).

UEFI Jellemzői


Szolgáltatások


Az EFI kétféle szolgáltatást határoz meg: boot szolgáltatások és futásidejű szolgáltatások.
A rendszerindítási szolgáltatások csak akkor érhetők el, ha a firmware tulajdonosa a platformnak (pl. A ExitBootServiceshívás előtt ), és szöveges és grafikus konzolokat tartalmaz különböző eszközökön, valamint busz-, blokk- és fájlszolgáltatásokat.
A futásidejű szolgáltatások továbbra is elérhetők az operációs rendszer futásakor; olyan szolgáltatásokat tartalmaznak, mint a dátum, az idő és az NVRAM- hozzáférés.
Emellett a grafikus kimeneti protokoll (GOP) korlátozott futásidejű szolgáltatásokat nyújt; lásd még a Grafikus funkciók részben.
Az operációs rendszer közvetlenül a GOP által biztosított framebufferre írható futtató módban.
Azonban a videomódok megváltoztatásának képessége elvész, miután átállt a futásidejű szolgáltatások módba, amíg az operációs rendszer grafikus meghajtó betöltődött.
2.3.2 és 2.3.4 -as verziótól 3,15, a Linux kernel támogatja a 64 bites kernel kell csizmás 32 bites UEFI firmware implementáció fut x86-64 CPU, a UEFI átadásaz UEFI boot betöltőjének támogatása, mint követelmény.
Az UEFI átadási protokoll deduplikálja az UEFI inicializálási kódot a kernel és az UEFI boot-betöltők között, és az inicializálást csak a Linux kernel UEFI boot stubja végzi.
Változó szolgáltatások
Az UEFI változók lehetővé teszik az adatok, különösen a nem illékony adatok tárolását, amelyek megosztottak a platform firmware és az operációs rendszerek vagy az UEFI alkalmazások között.
A változó névtereket a GUID-k azonosítják, a változók kulcs / érték párok.
Például a változók használhatóak az összeomlásüzenetek NVRAM-be történő megtartása után, amikor az operációs rendszer újraindulása után letöltésre kerül.
Időszolgáltatások
Az UEFI eszköz-független időszolgáltatásokat biztosít.
Az időszolgáltatások közé tartozik az időzónának és a nyári időszámításnak megfelelő mezők támogatása, amelyek lehetővé teszik a hardver valós idejű órájának helyi idő vagy UTC beállítását.
A PC-AT valós idejű órát használó gépeken alapértelmezés szerint a hardver órát a helyi idő szerint kell beállítani a BIOS-alapú Windows kompatibilitással, kivéve, ha a legfrissebb verziókat és a Windows rendszerleíró bejegyzést használja beállítja az UTC használatát.

Alkalmazások


Az operációs rendszer betöltése mellett az UEFI olyan UEFI alkalmazást is futtathat , amely az EFI rendszer partíción fájlként található.
Ezek végrehajthatók az UEFI parancs shellből, a firmware rendszerindító kezelőjéből vagy más UEFI alkalmazásokból.
Az UEFI alkalmazások a rendszer gyártójától függetlenül fejleszthetők és telepíthetők.
Az UEFI alkalmazás típusa egy OS betöltő, mint például a GRUB , az rEFInd , a Gummiboot és a Windows Boot Manager ; amely betölti az OS-fájlt a memóriába és végrehajtja.
Az operációs rendszer betöltője egy felhasználói felületet is képes biztosítani, amely lehetővé teszi egy másik UEFI alkalmazás futtatását.
Az UEFI shellhez hasonló segédprogramok szintén UEFI alkalmazások.

Protokolok


prot.png Az EFI a protokollokat két bináris modul közötti kommunikációhoz használt szoftver interfészek készletévé definiálja.
Valamennyi EFI-illesztőprogramnak protokollal kell másoknak szolgáltatásokat nyújtania.

Illesztőprogramok


A szabványos, processzor-eszközillesztő, EFI előírja a processzor független eszközmeghajtó memóriában tárolt mint EFI byte-kódot vagy EBC.
A rendszer firmware-nek van egy tolmácsa az EBC képekhez. Ebben az értelemben az EBC hasonló az Open Firmware-hez , a PowerPC- alapú Apple Macintosh és a Sun Microsystems SPARC számítógépekhez használt hardverfüggetlen firmware-hez.
Egyes architektus-specifikus (nem EFI byte-kódhoz) EFI illesztőprogramok bizonyos eszköztípusokhoz interfészek lehetnek az operációs rendszer számára.
Ez lehetővé teszi az operációs rendszernek, hogy az EFI-re támaszkodjon az illesztőprogramok számára az alapvető grafikus és hálózati funkciók elvégzésére, és ha az operációs rendszert futtató illesztőprogramok betöltődnek.

Grafikai jellemzők


Az EFI specifikáció meghatározta az UGA (Univerzális grafikus adapter) protokollt, amely az eszköz-független grafika támogatását jelenti.
Az UEFI nem tartalmazta az UGA-t és helyettesítette GOP-val (grafikus kimeneti protokoll), azzal a kifejezett céllal, hogy eltávolítsa a VGA hardverfüggőségeket.
A kettő hasonló.
Az UEFI 2.1 egy "Humán Interfész Infrastruktúrát" (HII) definiált a felhasználói bevitel, a helyi karakterláncok, betűtípusok és űrlapok (HTML értelemben vett) kezelésére.
Ezek lehetővé teszik az eredeti gyártók (OEM) vagy a független BIOS-gyártók (IBV) számára, hogy grafikus interfészeket tervezzenek az indítás előtti konfigurációhoz; Az UEFI maga nem határoz meg felhasználói felületet.
A legtöbb korai UEFI firmware-implementáció konszolidált volt, de 2007-ben néhány implementáció grafikus felhasználói felületet tartalmazott.

EFI rendszer partíció


Az EFI rendszerpartíció, amelyet gyakran ESP-nek rövidítenek, olyan adat tárolóeszköz- partíció, amelyet az UEFI-specifikációhoz csatlakozó számítógépekben használnak.
Az UEFI firmware-hez hozzáférve, amikor a számítógépet bekapcsolják, tárolja az UEFI alkalmazások és az ezekhez az alkalmazásokhoz szükséges fájlokat, beleértve az operációs rendszermagokat is.
Támogatott partíciós tábla rendszerek magukban MBR és GPT , valamint El Torito kötetek optikai lemezek.
Az ESP-ken való használathoz az UEFI meghatározza a FAT fájlrendszer egy speciális verzióját, amelyet az UEFI specifikáció részeként tartanak fenn, és függetlenül az eredeti FAT specifikációtól, amely magában foglalja az ESP-eken lévő FAT32 fájlrendszer egyik változatát , valamint a cserélhető adathordozók FAT16 és FAT12 fájlrendszereit.
Az ESP helyet biztosít a boot szektor számára a visszafelé irányuló BIOS kompatibilitás részeként.

UEFI bootolás


A BIOS-tól eltérően az UEFI nem támaszkodik boot szektorra , hanem az UEFI specifikáció részeként egy boot-menedzsernek.
Amikor a számítógép be van kapcsolva, a rendszerindító felügyeli a rendszerindítási konfigurációt, és a beállítások alapján betölti a memóriába, majd végrehajtja a megadott OS betöltőt vagy operációs rendszermagot.
A rendszerindítási konfigurációt az NVRAM- ban tárolt változók határozzák meg , beleértve azokat a változókat is, amelyek a fájlrendszer elérési útvonalát mutatják a OS töltők és OS rendszermagok számára.
Az OSFI automatikusan észleli a OS betöltőket, ami lehetővé teszi az eltávolítható eszközök, például az USB flash meghajtók könnyű indítását.
Ez az automatikus felismerés szabványos fájl elérési útvonalakra támaszkodik az operációs rendszer betöltőjével, és az elérési út a számítógépes architektúrától függően változik . A fájl elérési útjának formátuma / EFI / BOOT / BOOT .EFI ; például az x86-64 rendszer OS betöltőjének fájl elérési útja az /efi/BOOT/BOOTX64.EFI, és az efi \ boot \ bootaa64.efi az ARM64 architektúrán.
Az UEFI rendszerek indítása GPT partíciós lemezekről általában UEFI-GPT indításnak nevezik.
Annak ellenére, hogy az UEFI-specifikáció teljes támogatást igényel az MBR partíciós táblákhoz, néhány UEFI firmware-implementáció azonnal átvált a BIOS-alapú CSM-indításra a rendszerindító lemez partíciótáblájától függően, hatékonyan megakadályozza, hogy az UEFI-boot Az EFI rendszer partíciói MBR partíciós lemezekre.
Az ilyen boot rendszereket általában UEFI-MBR-nek hívják.
Az is gyakori, hogy a rendszerindító kezelőnek legyen szöveges felhasználói felülete, így a felhasználó kiválaszthatja a kívánt operációs rendszert (vagy rendszer segédprogramot) a rendelkezésre álló rendszerindítási lehetőségek listájáról.

Firmware problémák


Az eszközök UEFI firmware-jének megnövekedett előfordulása számos technikai problémát is eredményezett, amelyek a saját implementációikra támaszkodtak.
A Windows 8 kiadásának megjelenése után 2012 végén felfedezték, hogy bizonyos biztonságos indítású Lenovo számítógépes modellek firmware-t tartalmaztak, amely hardkódolt, hogy csak a " Windows Boot Manager " vagy a " Red Hat Enterprise Linux " nevű futtatható fájlokat tudja betölteni, bármilyen más beállítás.
További problémák merültek fel a Toshiba laptopok biztonságos indításával, amelyek hiányoztak a megfelelő működéséhez szükséges tanúsítványok.
2013 januárjában, egy hiba körülvevő UEFI végrehajtásának egyes Samsung laptopok nyilvánosságot kapott, ami miatt számukra, hogy falazott telepítése után egy Linux disztribúció UEFI-módban.
Míg esetleg összeütközésbe kerültek a rendszermodulhoz a Samsung laptopok rendszerfunkcióinak elérésére tervezett problémákkal, a hibák kudarcát keltették (ez arra is ösztönözte a rendszermag fenntartóit, hogy biztonsági okokból kikényszerítsék a modult az UEFI rendszereken), Matthew Garrett felfedezte, hogy a hibát tényleg túl sok UEFI változókat a memóriába, és hogy a hiba bizonyos feltételek mellett Windows alatt is kiváltható.
Összegezve megállapította, hogy a sértő rendszermag modul okozta a rendszermag üzenetet a firmware-be írva, ily módon kiváltva a hibát.
Köszönöm szépen azt, hogy végigolvastad ezt a cikket, további jó böngészést.