Hva er EFI-filformatet?
En .efi-fil er en systemfil som brukes av datasystemer og enheter basert på x86-64 og ARM-basert maskinvare. En .efi-fil inneholder kjørbar kode som kjører mellom fastvare- og operativsystemnivået - teknisk sett er det et PE32+ Portable Executable-bilde med en UEFI-spesifikk subsystem-verdi i stedet for et standard Windows-subsystem.
Bruk av .efi-filer
.efi-systemfiler brukes under systemets oppstartsprosess, for klargjøring av fastvareoppdateringer og kjøring av programmer før oppstart. .efi-filer lar systemet overlevere prosesser før oppstart til et kontrollert miljø. Vanlige eksempler inkluderer bootmgfw.efi (Windows Boot Manager), grubx64.efi (GRUB-bootloader for Linux) og shimx64.efi (Secure Boot-shim). Noen ganger er .efi-filer inkludert i pakker for fastvareoppdatering og lastes under oppstartsprosessen. Alle .efi-binærfiler må ligge på EFI-systempartisjonen (ESP) - et FAT32-volum på en GPT-partisjonert disk som fastvaren har tilgang til før noen OS-driver lastes inn.
EFI og UEFI-spesifikasjonen
EFI-standarden ble opprinnelig utviklet av Intel. EFI ble senere oppdatert og ble kjent som UEFI (Unified Extensible Firmware Interface), som har erstattet det eldre Basic Input/Output System (BIOS) på praktisk talt alle moderne PC-er og servere. UEFI Forum, et industrikonsortium, vedlikeholder nå spesifikasjonen.
Sikkerhet og trygghet
RISIKO: MEDIUMEn .efi er kjørbar kode som kjører på et svært privilegert tidspunkt - før operativsystemet, med full tilgang til fastvaren - så en ONDSINNET .efi (et «bootkit») kan være farlig og vedvarende. Moderne PC-er begrenser dette med UEFI Secure Boot, som nekter å kjøre .efi-binærfiler som ikke er signert med en betrodd nøkkel. Praktisk veiledning: plasser eller kjør aldri en ukjent .efi i EFI-systempartisjonen din, og ikke start fra en utroverdig .efi; hold Secure Boot aktivert med mindre du har en spesifikk grunn til å la være. Den motsatte risikoen er like reell: sletting eller omdøping av legitime .efi-filer i ESP (f.eks. bootmgfw.efi, grubx64.efi) kan gjøre maskinen umulig å starte - la dem være i fred med mindre du bevisst reparerer bootloaderen.
Formatdetaljer
i et nøtteskall- Adobe Encapsulated/innebygd skrifttype eller HP-skriverfastvare - Noen få urelaterte produkter har historisk brukt .efi for interne data; på en PC er nesten hver .efi du møter en UEFI-oppstartsfil.
Programmer som åpner EFI-filer
Windows3 apps
UEFI firmware (the motherboard itself)
Innebygd En .efi KJØRES, ikke åpnes: fastvaren utfører den ved oppstart (f.eks. via oppstartsmenyen / oppstartsrekkefølgen). Du dobbeltklikker den ikke i Windows.
EDK II (TianoCore)
Åpen kildekode For utviklere: referanse-UEFI SDK for å bygge, inspisere og feilsøke .efi-applikasjoner/drivere.
PE viewer (e.g. PE-bear / CFF Explorer)
Åpen kildekode For å INSPISERE hva en .efi er, åpne den som en PE-fil og sjekk Subsystem-feltet (10/11/12 = EFI). Kjører den ikke. 
macOS1 app
EDK II (TianoCore)
Åpen kildekode For utviklere: referanse-UEFI SDK for å bygge, inspisere og feilsøke .efi-applikasjoner/drivere. 
Linux2 apps
UEFI firmware + efibootmgr
Åpen kildekode Administrer hvilken .efi-bootloader fastvaren starter (oppstartsoppføringer/rekkefølge) fra Linux; selve .efi-filen kjører ved oppstart.
EDK II (TianoCore) / GNU-EFI
Åpen kildekode Bygg og inspiser UEFI .efi-binærfiler; kjør/test dem i det virtuelle UEFI-miljøet QEMU+OVMF. Tekniske detaljer
dyp spesifikasjon| Filsignatur | `MZ` (hex `4D 5A`) ved offset 0 - DOS-stub; PE-signatur (bytes `50 45 00 00`) ved offset gitt av 4-byte LE-pekeren ved header-offset `0x3C` |
| Grunnleggende binærformat | PE32+ (64-bit Portable Executable) - samme beholderformat som en Windows `.exe`, kun differensiert av verdien i PE Subsystem-feltet |
| Verdier i PE subsystem-felt | 10 = EFI Application; 11 = EFI Boot Service Driver; 12 = EFI Runtime Driver; 13 = EFI ROM Image |
| MIME-type | `application/efi` |
| Støttede CPU-arkitekturer | x86-64 (IA-32e), IA-32, ARM Thumb-2, AArch64, RISC-V 32/64/128, IA-64 (Itanium) - arkitektur kodet i PE Machine-feltet |
| Påkrevd partisjon og filsystem | EFI-systempartisjon (ESP) formatert som FAT12, FAT16 eller FAT32 på en GPT-partisjonert disk; NTFS og ext4 støttes ikke naturlig av UEFI-fastvare |
| Standard installasjonssti på ESP | `\EFI\<Vendor>\<name>.efi` - f.eks. `\EFI\Microsoft\Boot\bootmgfw.efi` eller `\EFI\ubuntu\grubx64.efi` |
| Secure Boot-kodesignering | Signert med Authenticode (RSA + SHA-256); verifisert mot UEFI Secure Boot-nøkkeldatabaser: PK (Platform Key), KEK, `db` (tillatt) og `dbx` (trukket tilbake) |
| Prototype for inngangspunkt | `EFI_STATUS EFIAPI ImageEntry(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)` - samme signatur for alle EFI-applikasjonstyper |
| Privilegier ved kjøring | Høyeste CPU-privilegier - ring 0 (CPL0) på x86; EL1 eller EL2 på AArch64 - i et flatt adresserom før OS med direkte maskinvaretilgang |
| Boot Service vs. Runtime-opphold | Boot Service-drivere (subsystem 11) fjernes fra minnet når operativsystemet kaller `ExitBootServices()`; Runtime-drivere (subsystem 12) forblir mappet etter overlevering til OS |
| Krav til diskpartisjonering | GPT (GUID Partition Table) kreves for naturlig UEFI-oppstartsmodus; disker med kun MBR støttes ikke |
| Vanlige kjente binærfiler | `bootmgfw.efi` (Windows Boot Manager), `grubx64.efi` (GRUB), `shimx64.efi` (Secure Boot-shim), `Shell.efi` (interaktivt UEFI-skall) |
| Verktøykjeder for bygging | EDK II (TianoCore), GNU-EFI, LLVM/clang med `-target x86_64-unknown-uefi`; utdata må lenkes som et PE32+-bilde med UEFI-subsystemflagg |
| Utgitt | EFI 1.0 (Intel, ~2000) → UEFI 2.x (UEFI Forum, 2005+); standard on PCs since ~2012 |
| Åpen standard | Ja · royalty-fri |
| Spesifikasjon | uefi.org |
EFI-konverteringer
Spørsmål og svar fra fellesskapet
spurt av brukereIngen spørsmål ennå - vær den første til å spørre om EFI-filer.
