Every command and hex dump in this post was run live on this machine (uname -r: 7.2.4-arch1-2) against its real /boot/vmlinuz-linux. Nothing here is a mockup — you can reproduce every byte on your own box.
Your Linux kernel image (/boot/vmlinuz-*) starts with the two bytes\n4D 5A — "MZ" — the ancient MS-DOS executable magic number, followed a\nlittle further in by a real "PE\\0\\0" (COFF) header with\nSubsystem = IMAGE_SUBSYSTEM_EFI_APPLICATION. This is not a coincidence, a\njoke, or legacy cruft nobody bothered to remove. It’s required by the\nUEFI specification: UEFI firmware only knows how to load and execute\nPE32+ binaries. To let a UEFI system boot Linux with zero extra\nbootloader code, the kernel’s boot header was made to also be a\nvalid PE/COFF executable — while simultaneously remaining a valid\nlegacy BIOS boot sector for machines that don’t have UEFI at all. Same\nbytes, two boot protocols.
$ file /boot/vmlinuz-linux\n/boot/vmlinuz-linux: Linux kernel x86 boot executable, bzImage, ...\n32-bit EFI handoff entry point, 64-bit EFI handoff entry point, ...\n$ xxd -l 4 /boot/vmlinuz-linux\n00000000: 4d5a 0000 MZ..A few things this post leans on, from scratch:
\nMZ / PE :MZ is the magic number of the old MS-DOS executable
format (.EXE ), named after Mark Zbikowski, one of its authors at\nMicrosoft. Windows NT’s executable format,PE (Portable\nExecutable,.exe /.dll /.efi /.sys ), is backward-compatible with it\non purpose: a PE filestarts with a real MS-DOS header (so old DOS\nwould print “This program cannot be run in DOS mode” instead of\ncrashing), and at a fixed offset — byte0x3C — that DOS header stores\na 4-byte pointer callede_lfanew , pointing forward to where thePE\\0\\0 header begins. Everything between the DOS header and the PE\nheader is technically a tiny, real, runnable DOS program (the “DOS\nstub”).
UEFI : the modern replacement for BIOS. Critically for this post,**the UEFI spec defines its executables as PE32+ (PE32 for 64-bit
address space) images** — UEFI firmware, at its core, is a minimal\nPE-loader. Anything you want firmware toLoadImage() /StartImage() directly — a bootloader, a driver, a recovery tool — has to be a valid\nPE/COFF binary withSubsystem = IMAGE_SUBSYSTEM_EFI_APPLICATION .
The old BIOS way : BIOS doesn’t know or care about executable
formats. It just loads the first 512-byte sector of a disk into memory\nand jumps to it, provided that sector ends with the magic bytes55 AA at offset0x1FE . Whatever’s in those 512 bytes is 100% up to you.
So: two completely different firmware interfaces, two completely different expectations about what a “bootable file” looks like. The Linux kernel image has to satisfy both, because it’s built once and needs to boot on both old BIOS machines and modern UEFI ones (directly, or via GRUB/systemd-boot, which themselves are PE binaries for the same reason).
\nLet’s actually parse vmlinuz by hand, no tools beyond xxd.
Byte 0 — the DOS magic:
\n$ xxd -l 64 /boot/vmlinuz-linux\n00000000: 4d5a 0000 0000 0000 0000 0000 0000 0000 MZ..............\n00000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................\n00000020: 0000 0000 0000 0000 0000 0000 0000 0000 ................\n00000030: 0000 0000 0000 0000 cd23 8281 4000 0000 .........#..@...4d 5a = "MZ". This is IMAGE_DOS_SIGNATURE. It has to be the very\nfirst two bytes of the file for any PE-format tool (or UEFI firmware)\nto even bother looking further.
Byte 0x3C — the e_lfanew pointer:
$ xxd -s 0x3c -l 4 /boot/vmlinuz-linux\n0000003c: 4000 0000 @...Little-endian 40 00 00 00 = 0x00000040. This says: “the PE\nheader starts at offset 0x40 in this file.” Every PE parser — including\nUEFI firmware’s own loader — reads this field to jump straight past the\nDOS stub.
Following the pointer — the PE/COFF header:
\n$ xxd -s 0x40 -l 32 /boot/vmlinuz-linux\n00000040: 5045 0000 6486 0400 0000 0000 0000 0000 PE..d...........\n00000050: 0100 0000 a000 0602 0b02 0214 0090 0601 ................Reading it field by field:
\noffset 0x40: 50 45 00 00 "PE\\0\\0" IMAGE_NT_SIGNATURE\noffset 0x44: 64 86 Machine = 0x8664 (AMD64)\noffset 0x46: 04 00 NumberOfSections = 4\noffset 0x48: 00 00 00 00 TimeDateStamp = 0 (reproducible build)\noffset 0x54: a0 00 SizeOfOptionalHeader = 0x00A0\noffset 0x56: 06 02 Characteristics = EXECUTABLE_IMAGE | ...\noffset 0x58: 0b 02 OptionalHeader Magic = 0x020B (PE32+)0x020B confirms this is a PE32+ image — the 64-bit PE variant,\nsame format used by every native 64-bit Windows .exe and every 64-bit\nUEFI driver.
The field that actually tells firmware “boot me”: Subsystem.
In a PE32+ optional header, Subsystem sits 68 bytes after the Magic\nfield (0x58 + 68 = 0x9C):
$ xxd -s 0x9c -l 4 /boot/vmlinuz-linux\n0000009c: 0a00 0001 ....0a 00 = 0x000A = 10 = IMAGE_SUBSYSTEM_EFI_APPLICATION. This\nsingle value is the whole point of the exercise: it’s the field UEFI\nfirmware checks to decide “this is an EFI application, I know how to run\nthis,” as opposed to IMAGE_SUBSYSTEM_WINDOWS_CUI (3, a normal Windows\nconsole app) or WINDOWS_GUI (2). Change one byte here and firmware\nwould refuse to load a byte-for-byte identical kernel.
The section table — proof it’s a real, structured PE image, not a\nfaked-up 4 bytes of magic:
\n$ xxd -s 0xf8 -l 40 /boot/vmlinuz-linux\n000000f8: 2e73 6574 7570 0000 0030 0000 0010 0000 .setup...0......\n00000108: 0030 0000 0010 0000 0000 0000 0000 0000 .0..............\n00000118: 0000 0000 4000 0042 2e63 6f6d 7061 7400 ....@..B.compat.Right after the optional header comes a normal PE section table, 40\nbytes per entry, each starting with an 8-byte ASCII name. This kernel\nimage declares (at least) four sections: .setup, .compat,\n.text, .data — a real PE loader will map these in exactly like it\nwould for notepad.exe.
Here’s the part that makes this genuinely clever rather than just “the\nkernel happens to be a PE file.” Jump to offset 0x1FE, the one place\nin a file that matters to old-school BIOS booting:
$ xxd -s 0x1fe -l 16 /boot/vmlinuz-linux\n000001fe: 55aa eb6a 4864 7253 0f02 0000 0000 0010 U..jHdrS........55 aa — the mandatory BIOS boot-sector signature, at exactly the\noffset BIOS requires it. Right after it: 48 64 72 53 = "HdrS", the\nmagic of the Linux kernel’s own setup_header structure (parsed by\nreal-mode bootloaders like GRUB’s legacy BIOS path, or even the kernel’s\nown built-in real-mode setup code). This is a completely different,\nolder, BIOS-era boot protocol, living in the exact same bytes as the\nPE header above it.
To see why this matters, compare against a pure EFI application on\nthe same disk — GRUB’s own grubx64.efi, which has no reason to ever be\nBIOS-bootable:
$ xxd -s 0x1fe -l 16 /boot/EFI/GRUB/grubx64.efi\n000001fe: 00c0 2e72 656c 6f63 0000 0020 0000 0050 ...reloc... ...P\n$ file /boot/EFI/GRUB/grubx64.efi\n/boot/EFI/GRUB/grubx64.efi: PE32+ executable for EFI (application),\nx86-64 (stripped to external PDB), 4 sectionsNo 55 AA at 0x1FE — because GRUB’s .efi binary doesn’t need one, it\nis only ever loaded by UEFI firmware, never by a BIOS jumping to a\ndisk sector. vmlinuz, on the other hand, deliberately keeps both\nmarkers valid at once:
| Offset | Bytes | Meaning | Consumed by |
|---|---|---|---|
0x000 | 4D 5A | "MZ" /e_lfanew @0x3C | Any PE loader, incl. UEFI |
0x040 | 50 45 00 00 | "PE\\0\\0" header,Subsystem=EFI_APPLICATION | UEFI firmware |
0x1FE | 55 AA | BIOS boot-sector signature | Legacy BIOS / GRUB legacy |
0x202 | 48 64 72 53 | "HdrS" , Linuxsetup_header | BIOS-era Linux bootloaders |
One 17 MB file. Two mutually exclusive, decades-apart boot protocols,\nboth satisfied simultaneously, because the byte ranges each protocol\nactually reads don’t overlap.
\nThis mechanism has a name: the EFI boot stub (CONFIG_EFI_STUB). It\nwas added to arch/x86/boot/header.S by Matt Fleming, first posted to\nLKML in October 2011 (“x86, efi: EFI boot stub support”). The kernel’s\nown documentation describes the goal directly:
On the x86 and arm platforms, a kernel zImage/bzImage is made to masquerade as a PE/COFF image, thereby convincing EFI firmware loaders to load it as an EFI executable.
\nAnnotated, based on the structure of arch/x86/boot/header.S:
.code16\n .section ".bstext", "ax"\n .byte 0xeb # short (2-byte) jump\n .byte start_of_setup-1f\n # ^ written as raw bytes, not a `jmp` mnemonic — the assembler\n # would otherwise emit a 3-byte jump and shift every fixed\n # offset below it, breaking the boot-sector/PE layout\n#ifdef CONFIG_EFI_STUB\n .org 0x3c\n .long pe_header # e_lfanew: offset to the PE header\n # (this is the value we read above: 0x40)\n .word IMAGE_DOS_SIGNATURE # "MZ" — must be bytes 0-1 of the file\n ...\npe_header:\n .long IMAGE_NT_SIGNATURE # "PE\\0\\0"\ncoff_header:\n .word IMAGE_FILE_MACHINE_AMD64\n .word section_count # NumberOfSections\n ...\noptional_header:\n .word PE_OPT_MAGIC_PE32PLUS # 0x020B\n ...\n .word IMAGE_SUBSYSTEM_EFI_APPLICATION # Subsystem = 10\n ...\n#endif /* CONFIG_EFI_STUB */The whole thing is #ifdef’d in specifically because it’s only\nneeded for EFI compatibility — a kernel built without\nCONFIG_EFI_STUB skips all of it and keeps the classic BIOS-only boot\nsector, no MZ/PE bytes at all.
The other side of the trick, drivers/firmware/efi/libstub/x86-stub.c,\nis the actual code that runs as the EFI application: it’s the\nefi_main() entry point UEFI firmware jumps to after LoadImage()\nsucceeds, which sets up the environment (memory map, initrd, command\nline) and hands off to the kernel’s normal decompression/startup path —\nthe same path a BIOS boot would eventually reach too. Both roads lead to\nthe same kernel; only the on-ramp differs.
This is also why you can boot a raw vmlinuz file directly from a UEFI shell or a UEFI boot entry, no GRUB required — that's the entire point of the EFI stub. systemd-boot and unified kernel images (UKIs) lean on exactly this property.
No special tools needed beyond xxd/file, which ship on essentially\nevery Linux box:
# 1. confirm the DOS/PE magic\nxxd -l 4 /boot/vmlinuz-linux # expect: 4d 5a 00 00\n# 2. follow e_lfanew to the PE header\noff=$(xxd -s 0x3c -l 4 -e /boot/vmlinuz-linux | awk '{print $2}')\nxxd -s "$((16#${off}))" -l 4 /boot/vmlinuz-linux # expect: 50 45 00 00 ("PE\\0\\0")\n# 3. read the Subsystem field (0x9c for a PE32+ boot header)\nxxd -s 0x9c -l 2 /boot/vmlinuz-linux # expect: 0a 00 -> 10 (EFI_APPLICATION)\n# 4. confirm it's still a legacy-bootable BIOS sector too\nxxd -s 0x1fe -l 2 /boot/vmlinuz-linux # expect: 55 aa\n# 5. let `file` do all of the above for you at once\nfile /boot/vmlinuz-linuxIf you want a broader sweep, grep/binwalk for the magic across your\nwhole /boot:
$ for f in /boot/vmlinuz-* /boot/EFI/*/*.efi; do\n sig=$(xxd -l 2 -p "$f" 2>/dev/null)\n [ "$sig" = "4d5a" ] && echo "$f: MZ present"\n done\n/boot/vmlinuz-linux: MZ present\n/boot/EFI/GRUB/grubx64.efi: MZ presentEvery UEFI-loadable file on the system starts the same way — the kernel\nis just the one that’s also something else at the same time.
\nMZ in vmlinuz isn’t legacy junk — it’s a spec requirement. UEFI
firmware is fundamentally a PE loader; anything meant to run under it\nhas to look like a PE binary, full stop, including the kernel.
One file, two file formats, zero conflict , because BIOS only ever
reads byte0x1FE and PE loaders only ever follow thee_lfanew pointer from0x3C — the two protocols were designed decades apart\nand happen not to step on each other’s bytes.
A single flipped bit can matter enormously.Subsystem = 10 is
the entire difference between “firmware treats this as a bootable EFI\napplication” and “firmware refuses to load it.” Worth remembering\nnext time a “cosmetic” header field looks safe to touch.
If you ever need to identify or fingerprint boot files during
forensics or malware triage: MZ + avalide_lfanew pointing at a\nrealPE\\0\\0 is a much stronger signal than the two magic bytes\nalone — check wheree_lfanew actually points before trusting the\nfile type.
arch/x86/boot/header.Sarch/x86/boot/setup.ld[PATCH v5 10/10] x86, efi: EFI boot stub support , Oct 2011e_lfanew ,IMAGE_SUBSYSTEM_* values)