Letölthetővé vált Windows 11 ISO ARM64 eszközökhöz a Microsofttól

Az Nvidia SOM-ok egy ideje már UEFI-t használnak. Sajnos.

Nem kell nagyon csodálkozni.

Ugyanaz a "díszes társaság", akinek először a PnP-t, majd az ACPI-t "köszönhetjük". Előbbivel még nem is volt annyira sok gond, de hogy öt évig senki nem tudott egy épkézláb ACPI implementációt csinálni... az UEFI-vel meg mégjobban túltolták.

vajon minek hatására jutott el oda [...] Még egyszer mondom: FAT!

Erre konkrétan tudok válaszolni, mert azokkal az emberekkel dolgoztam, akik (korábban) eldöntötték. Az alábbiakat emlékezetből írom, úgyhogy elnézést az esetleges pontatlanságokért.

Amikor valamelyik kezdeti UEFI (talán még csak EFI) specifikáción dolgoztak, akkor kellett egy filesystem. A résztvevők közül senki sem akart teljesen új fs-t tervezni és implementálni. A Microsoft felajánlotta a FAT-et. Senki sem erősködött (sem a csoporton belül, sem azon kívül), hogy (pl.) ext2 legyen, a munkacsoport pedig örömmel elfogadta a felajánlást.

A felajánlás a Microsoft részéről azt jelentette, hogy nyilvánosságra hoztak egy FAT specifikációt, amely a felhasználási feltételeiben kikötötte, hogy csak UEFI driver írására lehet felhasználni. Az edk2-ben (= EFI Development Kit II; UEFI referencia implementációban) eredetileg nem is volt FAT driver -- egy külön repo-ban volt egy speciális "3-BSDL + additional terms" FAT driver, amely ennek a Microsoft specifikációnak az alapján készült, és így a kódot a Microsoft spec. feltételei kötötték.

(Itt azt kell észben tartani, hogy a UEFI munkacsoport számára a UEFI egy ABI, nem pedig API spec; tehát a munkacsoport elsődleges célja az volt (és ma is az), hogy olyan szoftverfejlesztők moduljai tudjanak szépen együttműködni, akik kizárólag zárt forrással dolgoznak.)

Ez volt az oka annak, hogy Fedora-ba és RHEL-be 2016 előtt nem kerülhetett bele az OVMF (az edk2-ben lévő Open Virtual Machine Firmware platform) csomag (amely arra jó, hogy QEMU/KVM virtuális gépeket ne legacy BIOS-sal (SeaBIOS) indíts, hanem UEFI-vel (OVMF)). Ugyanis a FatPkg fent körülírt licence -- az OVMF-be foglalt modulok közül egyedüliként -- korlátozta a felhasználási területet, így nem adta meg a nulladik szoftverrel kapcsolatos felhasználási jogot ("tetszőleges felhasználás"). Például a FAT driver-t nem lehetett volna arra használni, hogy annak alapján egy teljesen független OS-hez FAT driver-t írj. Konkrétabban: ütközött a Fedora csomagolási feltételeivel. Egy ideig ezért az OVMF csak a RHEL (6 vagy 7, már nem emlékszem pontosan, régen volt) "Supplementary Channel"-ben volt elérhető, amely nem volt támogatott, viszont nem csak open source csomagok lehettek benne.

Aztán az Intel leült tárgyalni a Microsoft-tal, és szívós munkával 2016 tavaszára meggyőzték őket, hogy konkrétan a FatPkg-t oldozzák fel a kötöttségek alól. A FatPkg-t április elején beolvasztották a külső repóból az edk2-be, BSD licenc alatt. Azóta van minden Linux disztróban OVMF. Mi anno éveket vártunk erre a Red Hat-nél (én 2011 novemberében kezdtem OVMF-fel foglalkozni), és amikor megtörtént, virtuálisan pezsgőt bontottunk.

Azt persze megtehettük volna, hogy az OVMF-et úgy fordítjuk, hogy nem tesszük bele a FAT drivert. Ezzel az volt a baj, hogy egy ilyen firmware bináris nem felelt volna meg a UEFI spec-nek (attól függetlenül, hogy valami más filesystem-hez egy szabad driver-t esetleg bele tudtunk volna-e tenni -- ha utóbbi létezett volna, vagy megírtuk volna). Ugyanis maga a spec követeli meg a FAT-et (más file-rendszereket lehet támogatni, és azóta már létezik pl. ext2 és UDF driver is, de a FAT muszáj).

A korlátozott felhasználású driver-t itt találod:

https://github.com/tianocore/edk2-FatPkg/tree/278d45c7f6c05cc3443126964…

A mai napig olvasható a licencben, a 3-BSDL után:

Additional terms: In addition to the forgoing, redistribution and use
of the code is conditioned upon the FAT 32 File System Driver and all
derivative works thereof being used for and designed only to read
and/or write to a file system that is directly managed by Intel's 
Extensible Firmware Initiative (EFI) Specification v. 1.0 and later 
and/or the Unified Extensible Firmware Interface (UEFI) Forum's UEFI 
Specifications v.2.0 and later (together the "UEFI Specifications"); 
only as necessary to emulate an implementation of the UEFI Specifications; 
and to create firmware, applications, utilities and/or drivers.

Ezzel összehasonlítva, az edk2-be már így került be (2-BSDL):

https://github.com/tianocore/edk2/commit/b9ec93308b33#diff-dbcde8440cd4…

diff --git a/FatPkg/License.txt b/FatPkg/License.txt
new file mode 100644
index 000000000000..2740e4dcacd1
--- /dev/null
+++ b/FatPkg/License.txt
@@ -0,0 +1,11 @@
+Copyright (c) 2006, Intel Corporation
+All rights reserved.
+
+This program and the accompanying materials are licensed and made available
+under the terms and conditions of the BSD License which accompanies this
+distribution. The full text of the license may be found at
+http://opensource.org/licenses/bsd-license.php
+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+

Szósz: ld. "Acked-by: Laszlo Ersek" a commit message végén.

Azért FAT az EFI partíció, mert a FAT egy jól dokumentált, nyílt fájlrendszer, nem kell a működtetéséhez komplex kód (szemben egy ext4-gyel vagy ZFS-sel), mindenféle eszköz támogatja. Ne feledd, hogy ez nem komplett OS alá kell, csak egy bootloader alá, és ott is csak annyi erejéig, hogy egy pár megás fájlt indítson. Pont azért esett erre a választás, mert az egyik legprimitívebb, legegyszerűbb fájlrendszer, ami közös nevező.

Egyébként meg nehogy azt hidd, hogy 100-200 megás FAT partíció overkill. Ha Windowst használsz csak, annak tűnhet, de ha multibootot, meg pl. Linuxot, ami tárolhat rajta több kernelverziót is, ott már vészesen tud fogyni a hely. A biztonság sem szempont, mert azt a Secure boot, meg aláírás garantálja, nem a FAT.

Másrészt meg a hagyományos BIOS boot még szarabb volt, eleve csak MBR partíciós táblát használhattál, ahol 4 elsődleges partícióra volták szorítva, ha ez nem volt elég, lehetett kiterjesztett, logikai partíciókkal zsonglőrködni, meg bootflag-ekkel szórakozni, és ha multibootot akartál, akkor az OS-ek egymás alatt átírták az MBR-ben az indítókódokat.

Egyébként az senki nem írja ám elő, hogy több száz megásnak kell lennie a FAT partíciónak. A szabványban nincs megszorítás, lehet EFI partíció akár egy FAT12-es floppy is, nem viccelek. Ez csak a modern OS-ek gyakorlata, hogy kicsit biztonsági tartalékot hagynak rá, hogy nehogy azért lehetetlenüljön el a rendszer működése, mert az EFI partíción elfogyott a hely, mert valaki spúr barom képes volt 100 megán spórolni a mai terabájtos olcsó tárolók korában. A másik oka a FAT32-nek, hogy a FAT12, FAT16-on a hosszú fájlnevek nem lennének támogatva.

Ha az elmult 3-4 evben 1x sikerult qemu foverziot lepni es meg igy is tobb foverzioval van lemaradva, akkor kb nem szamit semmit.