A read-only reverse-engineering study of Intel Haswell (4th Gen Core) firmware that delivers a 6-patch NRI (Native Raminit) series for the in-tree coreboot, plus a 16-layer verification harness proving it correct.
This project is GPLv2-licensed (see LICENSE). The closed firmware binaries (FSP, mrc.bin) are not included and are not redistributable.
The story in one sentence: coreboot's Haswell port uses a
closed mrc.bin blob for memory init. This project contributes
6 patches that make the in-tree GPL Haswell NRI (Native
Raminit) work for DDR3-1600 and S3 resume — replacing mrc.bin
entirely. The cross-referenced FSP 1.0 RE is bonus material
that documents what the closed mrc.bin blob does internally.
Naming: libre-fsp = "libre" (FSF-aligned freedom) + "FSP"
(the closed Intel firmware being opened). The "libre" prefix
emphasizes that this is a freedom-respecting alternative to
Intel's proprietary FSP — not just "open source" but the full
four freedoms (use, study, modify, redistribute).
For new agents and contributors: see AGENTS.md for the complete reproducibility guide.
For the executive summary: see STATUS.md.
Firmware is the first software that runs when a computer powers on. It initializes the CPU, memory, storage, and peripherals before the operating system takes over. Because it has full hardware access and runs before any security boundaries are established, firmware is one of the most security-sensitive layers in any computer.
On x86 systems, firmware has traditionally been:
- BIOS (Basic Input/Output System): the original IBM PC firmware, dating to 1981. 16-bit, no memory protection, no standard interface.
- UEFI (Unified Extensible Firmware Interface): the modern replacement, introduced in the late 1990s and standard since the 2000s. C-based, with a defined driver model, capable drivers, and a graphical setup interface. Most x86 machines ship with a UEFI firmware, almost always proprietary.
Both BIOS and UEFI implementations from PC vendors (Lenovo, Dell, HP, etc.) are typically:
- Closed-source binary blobs under NDA
- Opaque to inspection, audit, or modification
- Undocumented beyond the public UEFI specification
- Tied to specific hardware revisions
Open source firmware isn't just an ideological preference. It addresses concrete technical problems:
Security. Closed firmware has been the entry point for multiple high-impact vulnerabilities:
- ThinkPad firmware passwords stored as a reversible XOR (2016, Lenovo's closed firmware)
- Intel Management Engine (ME) vulnerabilities that allow remote code execution below the OS (e.g., SA 00086, 2017)
- LoJax (2018), the first UEFI rootkit in the wild
- BlackLotus (2022), UEFI bootkit bypassing Secure Boot
- LogoFAIL (2023), UEFI image parsing vulnerabilities
Open source firmware can be:
- Inspected for backdoors or unintentional vulnerabilities
- Reproducibly built and verified
- Patched promptly when vulnerabilities are found
- Audited by independent researchers without NDAs
Longevity. Vendor firmware support ends with the product lifecycle. Once a laptop is 3-5 years old, the vendor stops issuing firmware updates. New CPU vulnerabilities (Spectre, Meltdown, Downfall, etc.) require microcode updates, which ship through firmware. Without firmware updates, old hardware becomes a security liability even when the OS is up to date.
User control. Closed firmware means the user cannot:
- Inspect what code runs on their hardware
- Modify behavior (e.g., disable Intel ME, change boot order)
- Reclaim space (vendor firmware often includes bloat)
- Keep working hardware functional when the vendor drops it
Supply chain. Closed firmware is a supply chain risk because the binary is unverifiable. Open source firmware allows reproducible builds and signed binaries.
coreboot (formerly LinuxBIOS) is the open-source firmware project that this work builds on. Founded in 1999, it is:
- 25+ years of active development
- Bootable on hundreds of motherboards across x86, ARM, RISC-V
- The basis for ChromeOS firmware on all Chromebooks since 2012
- Used in embedded systems, servers (e.g., some Open Compute Project hardware), and core developer machines
- Licensed GPLv2
- Designed to load any payload: Linux directly, GRUB2, SeaBIOS, depthcharge, edk2, etc.
coreboot's architecture is intentionally minimal: it does the minimum hardware init needed, then hands off to a payload that boots the OS. This keeps the trusted code base small (typically <100K LoC for the core init).
For modern Intel chipsets, Intel provides closed-source firmware blobs. The exact form has changed over the years:
| Generation | Closed blob | Size | Scope |
|---|---|---|---|
| Sandy/Ivy Bridge (2011-2013) | mrc.bin |
~50-200KB | Memory init only |
| Haswell (2013-2015) | mrc.bin (coreboot) OR FSP 1.0 |
~190KB / ~512KB | Memory init, minimal silicon init |
| Skylake (2015-2017) | FSP 1.1 / 2.0 | 1-3MB | Memory + silicon init + FSP-O |
| Kaby Lake / Coffee Lake | FSP 2.0 / 2.1 | 1-4MB | Memory + silicon + early init |
| Modern (Comet, Alder, etc.) | FSP 2.2 | 2-8MB | Memory + silicon + Security Extension + more |
For Haswell specifically, coreboot uses a closed mrc.bin
blob (190KB, just the memory reference code) for the
src/northbridge/intel/haswell/haswell_mrc/ path. The FSP 1.0
binary (512KB, includes silicon init) is a related but
separate binary distributed by Intel. This project RE's the
FSP 1.0 to inform the NRI development, but the patches in
haswell-patchset/ actually replace mrc.bin, not FSP.
For Skylake and later, FSP 2.0/2.2 is mandatory and does much
more work (memory, silicon init, early init, security
extension). Replacing FSP 2.x is a much larger effort than
replacing mrc.bin for Haswell. This project focuses on
Haswell because that's where the closed blob is small and
tractable.
FSP binaries (where present) are:
- Closed-source, no source available
- Distributed as encrypted/obfuscated x86-64 blobs
- Required for boot on modern Intel hardware
- Subject to EULAs that prohibit disassembly and reverse engineering
The FSP-encoded body is obfuscated with the FSPD 0x87654321
magic at the entry, and the entire code section is XOR'd. The
encoding can only be undone by running the FSP, which is
prohibited by its EULA.
This creates a paradox for open source firmware on modern hardware:
- coreboot itself is GPL and audited
- The closed blob (mrc.bin for Haswell, FSP for Skylake+) is unauditable
- Without the closed blob, the system doesn't boot
- So the "open source" nature of coreboot is compromised by the closed blob it must call
This project addresses that paradox for Haswell specifically,
by completing the in-tree NRI (Native Raminit) to the point
where it can replace mrc.bin for memory init, and giving the
coreboot community a tested, verified alternative.
The path to fully open source firmware on modern Intel hardware requires replacing each closed blob with GPL-licensed equivalents. The work falls into several major areas:
| Area | Closed blob it replaces | Status |
|---|---|---|
| Memory init (NRI) | mrc.bin (Haswell) or FSP-M (newer) |
In progress (this project) |
| CPU init | None (always in coreboot) | Done |
| PCH init | Mostly in FSP / mrc.bin | Partially in coreboot |
| Intel ME | ME firmware (1.5-5MB) | Workarounds exist (me_cleaner) |
| Silicon (audio, SATA, USB, PCIe, IGD) | FSP-S (newer) | Partially in coreboot |
| Microcode | CPU microcode updates (closed but redistributable) | coreboot supports loading |
| Payload | OS bootloader (GRUB2, SeaBIOS, depthcharge, edk2) | Available, all open source |
| FSP-M (memory) | FSP-M binary (newer chipsets) | The NRI pattern could be extended to Skylake+ |
Native Raminit (NRI) is the focus of this project. NRI is
coreboot's GPL re-implementation of the memory reference code
(MRC) for a specific chipset. For Haswell, the NRI is at
coreboot/src/northbridge/intel/haswell/native_raminit/
(9,600 LoC, 28 files). It implements:
- DDR3 SPD parsing and timing extraction
- Frequency table (DDR3-800, 1066, 1333, 1600)
- Memory controller configuration (MCHBAR programming)
- DDR3 training (read leveling, write leveling, RX/TX centering)
- Power management (self-refresh, power-down, RAPL)
- Error correction (ECC)
The 6-patch series in this project (haswell-patchset/)
adds DDR3-1600 support and S3 resume to the Haswell NRI. These
patches are chipset-level (Haswell), not mainboard-level —
they apply to all Haswell hardware using the in-tree NRI,
including:
- T440p (the test case that drove this work) — ThinkPad with DDR3L-1600 SO-DIMMs
- T440 / T540 / W540 / X240 — other Haswell ThinkPads
- Intel NUC D54250WYK / D34010WYK — Haswell NUCs
- ASUS H81M-PLUS / H97M-E — desktop boards
- Any other board with Lynx Point PCH + Haswell CPU that uses the in-tree NRI
The T440p was chosen as the test case because it has DDR3-1600 SO-DIMMs and the most active community of users who wanted open source firmware on it. But the patches are not T440p-specific — any board using the in-tree Haswell NRI will benefit.
This project is one step in the multi-year effort to fully open-source Haswell firmware. Specifically:
-
6-patch NRI series (chipset-level, not mainboard-specific): enables DDR3-1600 and S3 resume on the in-tree Haswell NRI. Applies to any Haswell hardware using the NRI (T440p, T440, NUC, etc.). Two features the open-source firmware community has long requested.
-
FSP 1.0 RE docs (9 documents): structural analysis of the related FSP 1.0 binary, with the public ABI extracted and the ~22 MRC tasks catalogued from string anchors. Useful for understanding what
mrc.bindoes internally (since they implement the same MRC algorithm), and as a reference for extending the NRI to newer chipsets. -
16-layer verification harness: proves the patches are correct, the NRI produces the same MCHBAR programming as the FSP mrc.bin (91 demo writes, 89 NRI match, 81 NRI==FSP, 0 mismatches), and the NRI source compiles and runs under Unicorn 1.0.3 with bitfield-accurate struct assignments.
-
NRI-Unicorn compile-check harness: the only known way to run real NRI C code under a CPU emulator, by stubbing the dependencies and capturing MCHBAR writes through a shadow region at 0x90000000. Caught a real bitfield bug (
RX_TRAIN_RANKencoding). -
Reproducibility infrastructure: environment setup, dependency management, AGENTS.md, CONTRIBUTING.md, so that the work can be reproduced and extended by others.
The project also serves as a case study in how to reverse-engineer a closed firmware blob legally and ethically, and how to incrementally replace closed components with open-source equivalents.
| Component | What | Where |
|---|---|---|
| 6-patch NRI series | Chipset-level: DDR3-1600 + S3 resume + A0/LPDDR3/ECC guards for the in-tree Haswell NRI | haswell-patchset/ |
| NRI-Unicorn harness | Emulates the NRI's MCHBAR programming under Unicorn 1.0.3 | unicorn_harness/ |
| Verification harness | 16 layers of offline checks (no real hardware needed) | verify/ |
| FSP 1.0 RE docs | 9 docs covering the related FSP 1.0 binary (same MRC algorithm as mrc.bin) |
re-docs/ |
| FSP RE artifacts | 1,601 FSP strings, MRC task list, FSP_INFO_HEADER parsed | raw/ |
| FSP RE scripts | FV/FFS/FSPH parser, string extractor, API entry wrapper | scripts/ |
| Verify docs | 4 docs covering the harness, xref, compile-check | verify-docs/ |
-
The FSP is FSP 1.0 (3 API entries:
TempRamInit,FspInit,NotifyPhase) — a more limited API than FSP 1.1+ that coreboot'sfsp1_1driver assumes. -
The whole FSP image is a single UEFI PI Firmware Volume (FV) with one FFS file (the FSP file GUID
912740BE-2284-4734-b971-84b027353f0c) of type RAW. The FSP_INFO_HEADER is at file offset0x94, image-relative. -
The FSP image is loaded by the bootloader at the preferred base
0xfff60000(top-of-32-bit memory) and runs from there. -
The FSP image contains a complete PEI core (
PeiCore,PeiDispatcher,PeiServices,PeiInstallPeiMemory,PeiCreateHob) plus an MRC (memory reference code) and a silicon init module. -
The FSP body is FSP-encoded x86-64 (an instruction-level obfuscation keyed on the 4-byte magic
0x87654321aka "FSPD" at the FSP base). The plaintext region is only the 3 API entry stubs, the common dispatch helper, the metadata (FV/FFS/RAW/FSPH/VPD/UPD), and the embedded VBT/VBIOS. The encoded section cannot be decoded without running the FSP, which the legal posture forbids. -
The default UPD region (the template the BCT can patch) has a
'HSWLPT-U'signature at image-relative offset0x79d0and a0x55AAterminator 0x310 bytes later. It contains 42 PCDs covering SPD SMBus addresses, TSEG, IGD, audio, SATA, XHCI, EHCI, SMBus, board type, and FastBoot. -
The FSP supports HSW B0/C0 steppings and Lynx Point PCH B0 stepping. ULT stepping is not supported (the ULT stepping A0 silicon is rejected).
-
The FSP produces the standard FSP HOBs:
FSP_BOOTLOADER_TEMPORARY_MEMORY_HOB_GUID,FSP_NON_VOLATILE_STORAGE_HOB_GUID, and resource descriptor HOBs with the 3 FSP owner GUIDs. -
coreboot's open-source 9,600-line Haswell NRI implements ~75% of the FSP-M task list by file count; the missing ~25% maps cleanly to the strings "GDXC", "MemoryTrace", "ChannelHash", "RMT" — features the FSP includes that the in-tree NRI does not.
-
The FSP also embeds the VBT (
$VBT HASWELL) and a full Haswell PCI SVGA Option ROM ("1215Intel(R) HSW Mobile/Desktop PCI Accelerated SVGA BIOS") in the Si-init code path. -
The NRI-Unicorn compile-check caught a real bitfield bug in the original demo:
RX_TRAIN_RANKwas hardcoded as0x00010420with a wrongrcven=64<<10comment, but the actual NRI bitfield layout (rcven:9 bits 0-8,dqs_p:6 bits 14-9,dqs_n:6 bits 25:20) produces0x02004040. Only the C struct compiler catches this kind of error.
- 16/16 verification layers pass
- 91 demo MCHBAR captures (Layer 13), 89 NRI match, 81 NRI==FSP
- 47 compile-check captures (Layer 14), 47/47 bitfield-verified
- 0 mismatches across all 89 documented NRI values
- 6 T440p patches apply cleanly to coreboot
| File | Contents |
|---|---|
README.md |
this file — project entry point |
AGENTS.md |
complete reproducibility guide for agents |
STATUS.md |
executive summary with all numbers |
CHANGELOG.md |
release notes |
CONTRIBUTING.md |
how to contribute |
LICENSE |
GPLv2 |
re-docs/00-source-inventory.md |
provenance, legal posture, scope |
re-docs/01-binary-structural-analysis.md |
FV/FFS/FSPH walk, encoded section |
re-docs/02-task-map.md |
60+ MRC task map from string anchors |
re-docs/03-fsp-contract.md |
public FSP 1.0 contract |
re-docs/04-divergence-from-hsw-nri.md |
what FSP does that NRI doesn't |
re-docs/05-references.md |
EAS PDFs, datasheets, public sources |
re-docs/06-mrc-verification-depth.md |
mrc.bin L1-L5 Unicorn ladder |
re-docs/07-mrc-ghidra-re.md |
MRC body RE |
re-docs/08-haswell-port-audit.md |
T440p port audit |
verify-docs/09-unicorn-emulation-survey.md |
Phase 1 NRI MMIO surface |
verify-docs/10-unicorn-emulation-harness.md |
MCHBAR shadow capture |
verify-docs/11-mchbar-crossref.md |
NRI vs FSP mrc.bin xref (91 writes) |
verify-docs/12-nri-compile-check.md |
compile-check (47 writes) |
raw/ |
1,601 FSP strings, MRC task list, FSP_INFO_HEADER |
scripts/ |
FV/FFS/FSPH parser, string extractor |
For every claim, the document cites the source — whether the
binary, a public header, a public datasheet, or the GPL coreboot
code. The "Legal posture" section of
re-docs/00-source-inventory.md is the controlling document for
what was and was not done.
The FSP binary was not executed. The FSP binary was loaded into a
RE tool (Ghidra, IDA-class) as a raw binary at the FSP preferred
base 0xfff60000 and disassembled at the three plaintext API
entry points only. The FSP-encoded section was identified by
structural signature but not decoded (would require running the
FSP, which the legal posture forbids).
- This is not a redistributable copy of the FSP binary or
mrc.bin. The closed blobs are not in this package. - This is not a complete re-implementation of the FSP. The 6
NRI patches replace
mrc.binfor memory init, not the FSP for silicon init. Silicon init is partially in coreboot and partially in the FSP/mrc.bin blob (depending on the path). - This is not a copy of any leaked or proprietary source code. Where structural analysis of such sources informed the work, the conclusions are reported without naming the source.
- This is not a complete disassembly of the FSP-encoded code region. Decoding that region requires running the FSP, which the legal posture forbids.
- This is not legal advice. The legal posture section describes the project's working assumptions; consult counsel for any actual legal question.
# 1. Read the executive summary
cat STATUS.md
# 2. Read the reproducibility guide
cat AGENTS.md
# 3. Configure paths (interactive, or set env vars directly)
cd /path/to/this/project/verify
./setup-paths.sh # or: export COREBOOT_TREE=/path/to/coreboot && ...
# 4. Apply the NRI patches to your coreboot tree
cd $COREBOOT_TREE
git am $HSW_PATCHSET/00*.patch
# 5. Run the verify suite
cd /path/to/this/project/verify
./run_all.sh
# Expected: Results: 16 passed, 0 failed, 0 skipped
cat REPORT.md
# 6. Build coreboot for your Haswell board
cd $COREBOOT_TREE
make menuconfig # Select your mainboard (T440p, NUC, etc.)
make -j$(nproc)
# Output: build/coreboot.rom
# 7. Flash and test on real hardware
# (See AGENTS.md for flashing guidance)First public release: 2026-06-16. GPLv2. See CHANGELOG.md for the full release notes.
The T440p patch series (0002-0007) is at haswell-patchset/. The
FSP binary must be obtained separately (e.g., from
https://github.com/intel/FSP legacy branch) for Layers 8 and 10
to run; those layers will SKIP without it.
This project is one building block toward fully open source
firmware on Haswell-class hardware. The 6 NRI patches in this
release are sufficient to boot any Haswell hardware using the
in-tree NRI with DDR3-1600 SO-DIMMs and resume from S3
suspend, using the in-tree coreboot + NRI without any mrc.bin
or FSP call for memory init (other than for silicon init, which
is out of scope for this project).
The T440p was the test case that drove this work, but the patches apply to all Haswell hardware using the NRI:
| Mainboard | Status |
|---|---|
| ThinkPad T440p | Test case; DDR3L-1600 SO-DIMMs verified |
| ThinkPad T440 / T540 / W540 / X240 | Should work; same Lynx Point PCH + Haswell CPU |
| Intel NUC D54250WYK / D34010WYK | Should work; tested by community |
| ASUS H81M-PLUS / H97M-E | Should work; same chipset |
| Lenovo M93p / M4500 / etc. | Should work; same chipset |
| Any Lynx Point + Haswell board | Should work; verify Kconfig matches |
Once any of these boots with the NRI, the remaining dependencies on closed blobs are:
- ME firmware (Intel Management Engine): 1.5-5MB closed blob that ships with the machine. Required for boot. Can be partially neutralized with me_cleaner but not removed entirely.
- CPU microcode updates: redistributable but binary.
- GPU VBIOS: for integrated graphics, 36-64KB. Required if you want native display output.
- EC firmware: embedded controller on the laptop, controls power, keyboard, fans. Vendor-specific binary.
Replacing each of these is a separate project. This project's contribution is the memory initialization and S3 resume, which are the hardest and most laptop-specific parts of the boot process.
If you want to contribute to open source firmware on Haswell or similar Intel hardware, here are good starting points:
- Use coreboot: install it on a supported laptop or server. Report bugs. Improve documentation. Test the NRI patches on your hardware (T440, X240, NUC, etc.) and report whether DDR3-1600 + S3 resume work.
- Work on NRI: add the missing NRI features (2D margin,
command training, LPDDR3, ECC, RMT — see
re-docs/04-divergence-from-hsw-nri.mdfor the gap list). Or port the NRI pattern to Skylake, where the closed FSP is much larger and the same approach could replace it. - Replace more FSP functions: for Skylake+, the FSP also handles PCH init, audio, SATA, USB, PCIe, IGD. Each is a separate re-implementation effort.
- Improve me_cleaner: reduce the ME firmware footprint, document what's safe to remove, build tools for newer platforms.
- Port the NRI-Unicorn compile-check harness to other chipsets. The pattern (shadow MCHBAR region + bitfield-accurate struct stubs + Unicorn hook) works for any NRI.
- Document what you do: every hardware RE project benefits from the same legal-posture-first methodology used here.
See CONTRIBUTING.md for code style, prerequisites, and the verify-driven development workflow used in this project.