Hvad er EFI-filformatet?
En .efi-fil er en systemfil, der bruges af computersystemer og enheder baseret på x86-64 og ARM-baseret hardware. En .efi-fil indeholder eksekverbar kode, der kører mellem firmware- og operativsystemniveauet - teknisk set er det et PE32+ Portable Executable image med en UEFI-specifik subsystem-værdi frem for et standard Windows-subsystem.
Anvendelse af .efi-filer
.efi-systemfiler bruges under systemets opstartsproces, til klargøring af firmwareopdateringer og til at køre programmer før opstart. .efi-filer gør det muligt for systemet at overdrage processer før opstart til et kontrolleret miljø. Almindelige eksempler inkluderer bootmgfw.efi (Windows Boot Manager), grubx64.efi (GRUB-bootloader til Linux) og shimx64.efi (Secure Boot shim). Nogle gange er .efi-filer inkluderet i pakker med firmwareopdateringer og indlæses under opstartsprocessen. Alle .efi-binære filer skal ligge på EFI-systempartitionen (ESP) - en FAT32-enhed på en GPT-partitioneret disk, som firmwaren kan tilgå, før nogen OS-driver indlæses.
EFI og UEFI-specifikationen
EFI-standarden blev oprindeligt udviklet af Intel. EFI blev senere opdateret og blev kendt som UEFI (Unified Extensible Firmware Interface), som har erstattet det ældre Basic Input/Output System (BIOS) på stort set alle moderne PC'er og servere. UEFI Forum, et branchekonsortium, vedligeholder nu specifikationen.
Sikkerhed og tryghed
RISIKO: MEDIUMEn .efi er eksekverbar kode, der kører på et meget privilegeret tidspunkt - før operativsystemet, med fuld firmwareadgang - så en ONDSINDET .efi (et „bootkit“) kan være farlig og vedholdende. Moderne PC'er afbøder dette med UEFI Secure Boot, som nægter at køre .efi-binære filer, der ikke er signeret af en betroet nøgle. Praktisk vejledning: placer eller kør aldrig en ukendt .efi i din EFI-systempartition, og start aldrig fra en utroværdig .efi; hold Secure Boot aktiveret, medmindre du har en specifik grund til andet. Den modsatte risiko er lige så reel: sletning eller omdøbning af legitime .efi-filer i ESP (f.eks. bootmgfw.efi, grubx64.efi) kan gøre maskinen ude af stand til at starte - lad dem være i fred, medmindre du bevidst reparerer bootloaderen.
Formatdetaljer
kort fortalt- Adobe indkapslede/indlejrede skrifttyper eller HP-printerfirmware-blobs - Enkelte urelaterede produkter har historisk brugt .efi til interne data; på en PC er næsten enhver .efi, du møder, en UEFI-boot-binær fil.
Programmer der åbner EFI-filer
Windows3 apps
UEFI firmware (the motherboard itself)
Indbygget En .efi KØRES, ikke åbnes: firmwaren eksekverer den ved opstart (f.eks. via boot-menuen / boot-rækkefølgen). Du dobbeltklikker ikke på den i Windows.
EDK II (TianoCore)
Open-source For udviklere: reference-UEFI-SDK'et til at bygge, inspicere og fejlfinde .efi-applikationer/drivere.
PE viewer (e.g. PE-bear / CFF Explorer)
Open-source For at INSPEKTERE hvad en .efi er, kan du åbne den som en PE-fil og tjekke Subsystem-feltet (10/11/12 = EFI). Dette kører den ikke. 
macOS1 app
EDK II (TianoCore)
Open-source For udviklere: reference-UEFI-SDK'et til at bygge, inspicere og fejlfinde .efi-applikationer/drivere. 
Linux2 apps
UEFI firmware + efibootmgr
Open-source Administrer hvilken .efi-bootloader firmwaren starter (boot-indgange/rækkefølge) fra Linux; selve .efi-filen kører ved opstart.
EDK II (TianoCore) / GNU-EFI
Open-source Byg og inspicer UEFI .efi-binære filer; kør/test dem i det virtuelle QEMU+OVMF UEFI-miljø. Tekniske detaljer
dyb specifikation| Filsignatur | `MZ` (hex `4D 5A`) ved offset 0 - DOS stub; PE-signatur (bytes `50 45 00 00`) ved det offset, der er angivet af 4-byte LE-pointeren ved header-offset `0x3C` |
| Binært grundformat | PE32+ (64-bit Portable Executable) - samme containerformat som en Windows `.exe`, kun differentieret af værdien i PE Subsystem-feltet |
| Værdier for PE-subsystemfelt | 10 = EFI Application; 11 = EFI Boot Service Driver; 12 = EFI Runtime Driver; 13 = EFI ROM Image |
| MIME-type | `application/efi` |
| Understø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åkrævet partition og filsystem | EFI-systempartition (ESP) formateret som FAT12, FAT16 eller FAT32 på en GPT-partitioneret disk; NTFS og ext4 understøttes ikke indfødt af UEFI-firmware |
| Standard installationssti på ESP | `\EFI\<Vendor>\<navn>.efi` - f.eks. `\EFI\Microsoft\Boot\bootmgfw.efi` eller `\EFI\ubuntu\grubx64.efi` |
| Secure Boot-kodesignering | Signeret med Authenticode (RSA + SHA-256); verificeret mod UEFI Secure Boot-nøgledatabaser: PK (Platform Key), KEK, `db` (tilladt) og `dbx` (tilbagekaldt) |
| Entry point prototype | `EFI_STATUS EFIAPI ImageEntry(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)` - samme signatur for alle EFI-applikationstyper |
| Eksekveringsprivilegieniveau | Højeste CPU-privilegieniveau - ring 0 (CPL0) på x86; EL1 eller EL2 på AArch64 - i et fladt pre-OS adresserum med direkte hardwareadgang |
| Boot Service vs. Runtime-ophold | Boot Service-drivere (subsystem 11) fjernes fra hukommelsen, når operativsystemet kalder `ExitBootServices()`; Runtime-drivere (subsystem 12) forbliver mappet efter OS-overdragelse |
| Krav til diskpartitionering | GPT (GUID Partition Table) påkrævet for indfødt UEFI-opstartstilstand; diske med kun MBR understøttes ikke |
| Almindelige velkendte binære filer | `bootmgfw.efi` (Windows Boot Manager), `grubx64.efi` (GRUB), `shimx64.efi` (Secure Boot shim), `Shell.efi` (interaktiv UEFI-shell) |
| Build-værktøjskæder | EDK II (TianoCore), GNU-EFI, LLVM/clang med `-target x86_64-unknown-uefi`; output skal linkes som et PE32+ image med UEFI-subsystemflag |
| Udgivet | EFI 1.0 (Intel, ~2000) → UEFI 2.x (UEFI Forum, 2005+); standard on PCs since ~2012 |
| Åben standard | Ja · royaltyfri |
| Specifikation | uefi.org |
EFI-konverteringer
Fællesskabets Q&A
spurgt af brugereIngen spørgsmål endnu - vær den første til at spørge om EFI-filer.
