diff --git a/About/Heads-threat-model.md b/About/Heads-threat-model.md index 4b9c20a..e1db175 100644 --- a/About/Heads-threat-model.md +++ b/About/Heads-threat-model.md @@ -9,6 +9,21 @@ parent: About Heads Threat model {: .fs-8 .m-0 } + +
+ + Table of contents + + {: .text-delta } +1. TOC +{:toc} +
+ + +## Heads Threat Model + +### What makes Heads different + The threat model that Heads proposes to address is very different from that of [Tails](https://tails.boum.org). Tails's goal is to allow users to do computation on a machine in a way that doesn't leave in trace on that system. @@ -21,14 +36,14 @@ The threat model that Heads proposes to address is very different from that of * [LightEater malware seek GPG keys in Tails, Kallenberg and Kovah, 2015](https://www.theregister.com/2015/03/19/cansecwest_talk_bioses_hack/) * [Thunderstrike, Hudson 2014](https://trmm.net/Thunderstrike) -For these reasons, Tails is not sufficient for many users who want a laptop that +For these reasons, [Tails](https://tails.net/) is not sufficient for many users who want a laptop that they can travel with and want to have some assurances that most adversaries won't be able to modify the hardware underneath them. Complicating this goal is that modern x86 hardware is full of modifiable state [State considered harmful, Rutkowska 2015]({{ site.baseurl }}/PDFs/state_harmful.pdf) and it is full of dusty corners that can hide malware or unauthorized code. - Additionally there is unverifiable code running in the Intel Management Engine, + Additionally there is unverifiable code running in the [Intel Management Engine](https://www.intel.com/content/www/us/en/support/articles/000025619/software.html), which has access to memory, to the network and various other peripherals. As a result we must trust certain entities more than others and this does affect our threat model. @@ -39,19 +54,7 @@ This document discusses some of the threats that make building slightly more covers the practical issues of hardening a laptop against some of the threats described here. - -
- - Table of contents - - {: .text-delta } -1. TOC -{:toc} -
- - -Who do we trust -=== +### Who We Trust ![Flashing Chips]({{ site.baseurl }}/images/Flash_chips.jpg) @@ -63,11 +66,11 @@ As we consider building secure hardware, it is very important to keep in mind is hard to get around. * Intel (or other CPU manufacturer) - * Management Engine - * Microcode updates + * [Management Engine](https://www.intel.com/content/www/us/en/support/articles/000025619/software.html) + * [Microcode updates](https://www.intel.com/content/www/us/en/developer/topic-technology/software-security-guidance/processors-affected-consolidated-product-cpu-model.html) * Both are opaque and unknown outside of Intel -* TPM manufacturer - * Infineon/STM/etc +* [TPM](https://trustedcomputinggroup.org/resource/tpm-library-specification/) manufacturer + * [Infineon](https://www.infineon.com/cms/en/product/security-smart-card-solutions/optiga-embedded-security-solutions/optiga-tpm/)/STM/etc * Might have a bad RNG, undocumented commands to leak keys, etc * Might have government mandated backdoor (country dependent) * LPC or i2c bus can be snooped @@ -77,11 +80,11 @@ As we consider building secure hardware, it is very important to keep in mind * Did they install extra devices on the LPC bus? * Is there a key logger built into the keyboard? - * Funtennas for data leakage through motherboard traces [Funtenna uses software to make embedded devices broadcast data on radio frequencies, Ang Cui 2015](http://www.slate.com/blogs/future_tense/2015/08/05/_funtenna_uses_software_to_make_embedded_devices_broadcast_data_on_radio.html) + * Funtennas for data leakage through motherboard traces [Funtenna uses software to make embedded devices broadcast data on radio frequencies, Ang Cui 2015](https://www.slate.com/blogs/future_tense/2015/08/05/_funtenna_uses_software_to_make_embedded_devices_broadcast_data_on_radio.html) * Peripheral manufacturer * Firmware in drives, NICs, etc - * IOMMU is necessary to limit device access (but this does not always work + * [IOMMU](https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_management_unit) is necessary to limit device access (but this does not always work * against hostile devices) * Known target for "Equation Group" [The Equation Group, Kaspersky 2015](https://www.kaspersky.com/about/press-releases/2015_equation-group-the-crown-creator-of-cyber-espionage) Devices should never be presented with clear text data @@ -96,22 +99,205 @@ As we consider building secure hardware, it is very important to keep in mind * Deliberate tampering with HW/SW config * Can we implement two-key authentication to reduce chance of backdoors? -System Firmware ----- +### Evil Maid Attacks and Physical Threats + +Safes are rated in hours/minutes that a safe cracker requires to break into it. + Likewise some physical attacks can be done in a few seconds with only external + access, while others require disassembly of the device and hours of effort. + However, as Schneier says "Attacks only get better" + [New Cryptanalytic Results Against SHA-1, Scheiner 2005](https://www.schneier.com/blog/archives/2005/08/new_cryptanalyt.html) + , so time estimates for various methods are an upper bound. Likewise attacks + that are be limited to nation state adversaries today might be more practical + for average attackers in a few years time. + +An insider threat is especially difficult to counter since they have + unrestricted access to the device and can spent an arbitrary amount of time, + effort and expertise on breaking into it. Additionally, they potentially have + access to all of the keys that are not stored in non-exportable hardware (and + depending on their level of expertise they might be able to get them). + +Some threats assume that the adversary will modify the hardware, install + hardware or software measures, and return it to the owner. This is very similar + to an insider threat in that the machine will be returned to the owner and + possibly used to access private data while there might be unauthorized code + executing on the system. + +The "Evil Maid" attack was [coined by Joanna Rutkowska in 2009](https://theinvisiblethings.blogspot.com/2009/10/evil-maid-goes-after-truecrypt.html) +and named for a hotel maid or office cleaner who gains brief unsupervised +physical access. The classic attack: the maid boots the target laptop from +a malicious USB stick, infects the bootloader with a keylogger in under two +minutes, and leaves the laptop where it was found. When the owner returns +and types their disk encryption passphrase, it is captured. Heads addresses +this with TPMTOTP attestation -- the firmware must prove its integrity to +the user before any passphrase is entered. + +Related advanced attacks to be aware of: + +**Relay attack:** An attacker steals the laptop and leaves an +identical-looking malicious device in its place. The decoy relays the +TPMTOTP code from the real laptop to the user, who verifies the OTP as +correct and enters their passphrase -- which is then relayed to the +attacker holding the real device. This attack is difficult to defend +against, but [D-RTM](https://www.intel.com/content/www/us/en/developer/articles/technical/intel-trusted-execution-technology.html) and time/distance bounding protocols are areas of +active research. + +**TOTP secret extraction:** The TOTP shared secret must be unsealed from +the TPM to compute the 6-digit code, meaning it temporarily resides in RAM. +If an attacker gains physical access to the TPM, they can manually extend +PCR values to a known-good state and extract the secret. A stolen TOTP +secret allows an attacker to build a replica device that generates valid +OTP codes. [HOTP](https://datatracker.ietf.org/doc/html/rfc4226) with a hardware security token does not share this weakness +since the secret never leaves the token. + +**Suspend (S3) attack:** Heads verifies integrity at cold boot but does +*not* re-verify on resume from suspend. An attacker with brief physical +access could compromise a suspended system and leave a malicious lock +screen prompt. Best practice: shutdown (not suspend) when moving between +security domains, and use distinct passphrases for FDE decryption and +screen unlock. + +* Brief external physical access, with owner present + * Customs +* Brief external physical access, without owner present + * Classic "Evil Maid" -- bootloader infection, BIOS reflash + * Relay attack via substitute device + * Customs, in some countries +* Brief internal physical access + * Customs + * Specialized "Evil Maid", coldboot attacks + * Suspend-to-RAM compromise +* Extended external physical access + * Checked luggage +* Extended internal physical access + * Insider threat + * [TAO](https://en.wikipedia.org/wiki/Tailored_Access_Operations) "Evil Maid" or checked luggage +* Unbounded internal physical access + * Theft + * Insider threat + +For practical guidance on making hardware tamper-evident to detect these +attacks, the [anarsec tamper-evident guide](https://www.anarsec.guide/posts/tamper/) +provides detailed, tested techniques: +- Glitter nail polish on laptop case screws, photographed at known angles + and verified with the [Blink Comparison](https://github.com/proninyaroslav/blink-comparison) + Android app for quick before/after comparison. +- For travel and storage: store devices in transparent containers filled + with a colorful lentil/bean mosaic; photograph all six sides for later + verification. +- Tails USB: use a drive with a physical write-protect switch, and always + boot with it locked to prevent a compromised session from infecting the + USB itself. +These low-tech methods are a critical complement to Heads' firmware +integrity verification -- defense in depth means every layer counts. + +### Per-Board Protection Status + +The TPM GPIO reset vulnerability +([upstream coreboot bug #576](https://ticket.coreboot.org/issues/576)) +affects TPMTOTP evil maid detection and HOTP USB security dongle authentication +on platforms where coreboot does not lock the [PCH](https://www.intel.com/content/www/us/en/content-details/834810/intel-7th-generation-core-6th-generation-core-and-xeon-e3-1200-v6-families.html) GPIO pad configuration. +The TPM Disk Unlock Key with passphrase is **not affected** on any platform. + +{: .note } +Heads itself is **not** vulnerable -- the fix must come from [coreboot](https://doc.coreboot.org/). +See the [technical document](https://github.com/linuxboot/heads/blob/master/doc/TPM_GPIO_Reset_Vulnerability.md) +for details. + +| Board | CPU generation | EOL/ESU status | Evil Maid detection
(TPMTOTP attestation) | Disk encryption
(TPM DUK + passphrase) | USB Security Dongle
(HOTP authentication) | +|---|---|---|---|---|---|---| +| **X220** | 2nd Gen Sandy Bridge | ⚠️ EOL (no official ESU date; last microcode 2019-05-14) | ✅ Protected | ✅ Protected | ✅ Protected | +| **T420** | 2nd Gen Sandy Bridge | ⚠️ EOL (no official ESU date; last microcode 2019-05-14) | ✅ Protected | ✅ Protected | ✅ Protected | +| **X230** | 3rd Gen Ivy Bridge | ⚠️ EOL (no official ESU date; last microcode 2019-05-14) | ✅ Protected | ✅ Protected | ✅ Protected | +| **T430** | 3rd Gen Ivy Bridge | ⚠️ EOL (no official ESU date; last microcode 2019-05-14) | ✅ Protected | ✅ Protected | ✅ Protected | +| **T530** | 3rd Gen Ivy Bridge | ⚠️ EOL (no official ESU date; last microcode 2019-05-14) | ✅ Protected | ✅ Protected | ✅ Protected | +| **W530** | 3rd Gen Ivy Bridge | ⚠️ EOL (no official ESU date; last microcode 2019-05-14) | ✅ Protected | ✅ Protected | ✅ Protected | +| **Optiplex 7010/9010** | 3rd Gen Ivy Bridge | ⚠️ EOL (no official ESU date; last microcode 2019-05-14) | ✅ Protected | ✅ Protected | ✅ Protected | +| **HP Z220 CMT** | 3rd Gen Ivy Bridge | ⚠️ EOL (no official ESU date; last microcode 2019-05-14) | ✅ Protected | ✅ Protected | ✅ Protected | +| **T440p** | 4th Gen Haswell | ⚠️ EOL Jun 30, 2021 | ✅ Protected | ✅ Protected | ✅ Protected | +| **W541** | 4th Gen Haswell | ⚠️ EOL Jun 30, 2021 | ✅ Protected | ✅ Protected | ✅ Protected | +| **Librem L1UM v1** | 5th Gen Broadwell | ⚠️ EOL Jun 30, 2021 | ✅ Protected | ✅ Protected | ✅ Protected | +| **M900 Tower** | 6th Gen Skylake | ⚠️ EOL Sep 30, 2022 | ❌ Not protected | ✅ Protected | ❌ Not protected | +| **T480, T480s** | 8th Gen Kaby Lake-R | ⚠️ ESU Mar 31, 2026 ¹ | ❌ Not protected
[TPM GPIO reset bypass](https://mkukri.xyz/2024/06/01/tpm-gpio-fail.html) | ✅ Protected | ❌ Not protected | +| **Librem 13v2/v4, 15v3/v4** (Purism) | 5th-6th Gen Broadwell/Skylake | ⚠️ EOL varies | ❌ Not protected | ✅ Protected | ❌ Not protected | +| **Librem 14** (Purism) | 8th-10th Gen Coffee Lake | Active | ❌ Not protected | ✅ Protected | ❌ Not protected | +| **Librem 11** (Purism) | Jasper Lake | Active | N/A (no TPM hardware) | N/A (no TPM) | N/A (ROM-hash HOTP) | +| **Librem L1UM v2** (Purism) | 9th Gen Coffee Lake | Active | ❌ Not protected | ✅ Protected | ❌ Not protected | +| **Librem Mini v2** (Purism) | 10th Gen Comet Lake | Active | N/A (no TPM hardware) | N/A (no TPM) | N/A (ROM-hash HOTP) | +| **Librem Mini v1** (Purism) | 8th Gen Whiskey Lake | ⚠️ ESU Mar 31, 2026 | N/A (no TPM hardware) | N/A (no TPM) | N/A (ROM-hash HOTP) | +| **[NovaCustom](https://novacustom.com/) NV4x, [NitroPad NS50](https://shop.nitrokey.com/shop/product/nitropad-ns50-7)** ² | 12th Gen Alder Lake-P | Active | INCONCLUSIVE (unconfirmed) | ✅ Protected | INCONCLUSIVE (unconfirmed) | +| **NovaCustom V540tu/V560tu** | 14th Gen Meteor Lake | Active | ✅ Protected | ✅ Protected | ✅ Protected | +| **MSI Z690-A, Z790-P** | 12th-14th Gen | Active | ❌ Not protected | ✅ Protected | ❌ Not protected | +| **KGPE-D16** | AMD Family 15h | Unmaintained (reference only) | ✅ Protected | ✅ Protected | ✅ Protected | +| **Talos II** | POWER9 | Active | ✅ Protected | ✅ Protected | ✅ Protected | + +✅ Protected -- Heads' protection against this attack is intact on this board. + +❌ Not protected -- the TPM GPIO reset vulnerability bypasses Heads' TPMTOTP + and HOTP attestation on this board. An attacker with OS-level code execution + could reset the TPM and forge PCR measurements to extract the shared secret. + +INCONCLUSIVE (unconfirmed) -- the attack may or may not be feasible on this + platform. Hardware testing on ADL-P mobile (NV4x) showed [PLTRST#](https://en.wikipedia.org/wiki/Power_Management_Integrated_Circuit) assertion + cannot be confirmed without physical scope measurement. See the + [TPM GPIO Reset Vulnerability](https://github.com/linuxboot/heads/blob/master/doc/TPM_GPIO_Reset_Vulnerability.md) + document for per-platform technical status. + +¹ KBL-R falls under Whiskey Lake ESU (Mar 31, 2026). + +² ADL-P mobile (NV4x, NS50): mode bits hardware-locked; [PLTRST#](https://en.wikipedia.org/wiki/Power_Management_Integrated_Circuit) assertion not confirmed on this PCH die per NV4x ADL-P testing. + +{: .note } +TPM Disk Unlock Key (DUK) with passphrase is **not affected** on any board. +The DUK requires a user passphrase to unseal, which a GPIO reset cannot bypass. + +{: .note } +[KGPE-D16](https://doc.coreboot.org/mainboard/asus/kgpe-d16.html) is in `unmaintained_boards/`. Dropped from coreboot 4.12 (2019). +[Dasharo](https://docs.dasharo.com/) fork abandoned Aug 2025. AMD Family 15h microcode frozen since 2018. +See [BOARDS_AND_TESTERS.md](https://github.com/linuxboot/heads/blob/master/doc/BOARDS_AND_TESTERS.md#per-board-eolesu-status) +for details. + +See the coreboot patch series +[intel_gpio_lock](https://review.coreboot.org/q/topic:%22intel_gpio_lock%22) +for upstream fix status (patches [#90884](https://review.coreboot.org/c/coreboot/+/90884), [#90885](https://review.coreboot.org/c/coreboot/+/90885), [#93324](https://review.coreboot.org/c/coreboot/+/93324), [#93422](https://review.coreboot.org/c/coreboot/+/93422)). + +#### What this means for your threat model + +- If you rely on Heads for **evil maid detection** (checking the TOTP code + before entering your disk password), choose a board marked ✅ in the + first column. +- If you need **USB security dongle authentication** (HOTP), choose a board + marked ✅ in the last column. +- **Disk encryption** (TPM DUK with passphrase) is protected on all boards. + +For the current per-board technical status and fork verification details, see the +[Heads board testers list](https://github.com/linuxboot/heads/blob/master/doc/BOARDS_AND_TESTERS.md). + +### Firmware Security and Boot Integrity ![Flashing an x230 bootrom]({{ site.baseurl }}/images/Flashing_an_x230_bootrom.jpg) The firmware in the system's motherboard contains the code that the CPU executes - on startup. This is usually the BIOS or UEFI firmware and the complexity of it + on startup. This is usually the BIOS or [UEFI](https://uefi.org/) firmware and the complexity of it means that there are many possible attacks. [Thunderstrike](https://trmm.net/Thunderstrike) Too many UEFI vulnerablities to list... Intel has provided features like - Boot Guard to try to verify signatures on the firmware; this can hash the - firmware into the TPM PCR0 (Measured Boot) before the CPU starts or take more + [Boot Guard](https://www.intel.com/content/www/us/en/content-details/834810/intel-7th-generation-core-6th-generation-core-and-xeon-e3-1200-v6-families.html) to try to verify signatures on the firmware; this can hash the + firmware into the [TPM](https://trustedcomputinggroup.org/resource/tpm-library-specification/) PCR0 (Measured Boot) before the CPU starts or take more drastic measures like halting to boot process upon signature failure (Verified Boot). Silently failing to boot is not the best approach for most applications since it is not clear why the system has not started; measured boot allows detection of the malfeasance more directly. +It is important to distinguish Boot Guard's two modes. **Verified Boot** +permanently fuses the OEM's public key into the chipset -- if the firmware +is not signed by that key, the system refuses to boot. This prevents the +user from installing [Coreboot](https://doc.coreboot.org/) or any alternative firmware, and is typical +of "Enterprise Security" which prioritizes vendor control over user autonomy. +**Measured Boot**, by contrast, merely records the firmware hash into TPM +PCR0 so subsequent stages can check it; the user retains control. Heads +requires Measured Boot mode. Unfortunately, the mode is set at the factory +via field-programmable fuses and cannot be changed by the end user. +[Intel Boot Guard analysis, Ermolov](https://github.com/flothrone/bootguard) + ![CoreBoot + Linux + tpmtotp]({{ site.baseurl }}/images/TPMTOTP_in_use.jpg) Before the user enters a disk decryption password it must prove to the user that @@ -125,13 +311,13 @@ Before the user enters a disk decryption password it must prove to the user that compute a function on a shared secret and the current time, which allows the user to verify the output on a second mobile device or TOTP display token. -Trammell Hudson ported [mjg59's tpmtotp](https://mjg59.dreamwidth.org/35742.html) - to run from inside the boot ROM of a Thinkpad x230 using CoreBoot with a Linux +[Trammell Hudson](https://trmm.net/) ported [mjg59's tpmtotp](https://mjg59.dreamwidth.org/35742.html) + to run from inside the boot ROM of a Thinkpad x230 using [CoreBoot](https://doc.coreboot.org/) with a Linux payload. This provides attestation that the firmware hasn't been tampered with, - since the TPM won't unseal the secret to used in the TOTP HMAC unless the PCR + since the [TPM](https://trustedcomputinggroup.org/resource/tpm-library-specification/) won't unseal the secret to used in the TOTP HMAC unless the PCR values match those expected for the ROM image. -Garrett presented tpmtotp at 32c3 but Trammell Hudson felt that it +Garrett presented tpmtotp at 32c3 but [Trammell Hudson](https://trmm.net/) felt that it ran "too late" -- the system has already fetched the kernel and initrd from the disk and potentially had the chain of trust compromised. Since my version of code is executed from the difficult-to-write SPI flash ROM and the read-only @@ -139,16 +325,25 @@ Garrett presented tpmtotp at 32c3 but Trammell Hudson felt that it the rest of the ROM, it is much harder to compromise. Additionally, since my ROM image is very size constrained, Heads didn't want to use - OpenSSL and liboath and all of the other dependencies. My branch replaces them - with mbedtls and my own TOTP code, which reduces the size of the executables + [OpenSSL](https://www.openssl.org/) and liboath and all of the other dependencies. My branch replaces them + with [mbedtls](https://www.trustedfirmware.org/projects/mbed-tls/) and my own [TOTP](https://datatracker.ietf.org/doc/html/rfc6238) code, which reduces the size of the executables from 5MB to 180KB. The source is available from [github.com/osresearch/tpmtotp](https://github.com/osresearch/tpmtotp) and has since been merged into the Heads project. +**Note on TPMTOTP attestation and GPIO reset attacks:** On Intel platforms where +coreboot does not lock the PCH GPIO pad configuration, an attacker with OS-level +code execution can reset the TPM and forge PCR measurements, bypassing TPMTOTP +and HOTP attestation. The TPM Disk Unlock Key with passphrase is not affected. +See the [Per-Board Protection Status](#per-board-protection-status) section below +for which boards are affected, and +[TPM GPIO Reset Vulnerability](https://github.com/linuxboot/heads/blob/master/doc/TPM_GPIO_Reset_Vulnerability.md) +for technical details. + The UEFI firmware itself is also of great concern: is a very large code base and - most system firmwares are built from closed-source forks of the edk2 tree. This + most system firmwares are built from closed-source forks of the [edk2](https://github.com/tianocore/edk2) tree. This presents a problem for trusted systems since it is not possible to knows what else was included in the ROM image. Some vendors ship malware in the firmware - like Computrace + like [Computrace](https://www.kaspersky.com/about/press-releases/2014_good-software-can-go-bad) [Good Software can go Bad, Kaspersky 2014](https://www.kaspersky.com/about/press-releases/2014_good-software-can-go-bad) and others bundle rootkits into the boot rom @@ -163,105 +358,55 @@ The UEFI firmware itself is also of great concern: is a very large code base and Additionally there are many other things that we would like to do before handing control over to the OS on the harddrive and would like to develop them in a - comfortable open source environment. CoreBoot addresses both of these concerns - this by building a Linux kernel that is flashed into the system's boot ROM in - place of the UEFI image. There is still a need for some closed-source blobs + comfortable open source environment. [CoreBoot](https://doc.coreboot.org/) addresses + both of these concerns by building a [Linux kernel](https://www.kernel.org/) that is flashed into the + system's boot ROM in place of the UEFI image. There is still a need for some closed-source blobs (Intel's MRC and ME firmware, for instance), but the bulk of the vendor - provided code is gone. Instead of a boot loader like Grub, Coreboot can invoke + provided code is gone. Instead of a boot loader like [Grub](https://www.gnu.org/software/grub/), Coreboot can invoke a Linux kernel stored in ROM with its own immutable ROM file system. This kernel and runtime is the bulk of Heads and is responsible for implementing the rest of the verification steps like tpmtotp and verifying the next stages - before kexec()'ing the real OS. + before [kexec()](https://man7.org/linux/man-pages/man2/kexec_load.2.html)'ing the real OS. Finally, once Coreboot has been flashed into the ROM, the write protect pins on the ROMs can be shorted to ground as an extra layer of protection. This - prevents any software re-writes of the ROM, even from the Management Engine or + prevents any software re-writes of the ROM, even from the [Management Engine](https://www.intel.com/content/www/us/en/support/articles/000025619/software.html) or other devices on the SPI bus. We do have to trust that the SPI Flash Chips don't have any backdoor write commands; for the extra paranoid new chips can be soldered in place of the vendor supplied one and covered in epoxy to prevent easy replacement by attackers. -File systems ----- - -To be written: read-only root, dm-verity, tpm anti-rollback counters, signed -kernels, etc. - -Peripheral Firmware ----- - -![Hard disk drive]({{ site.baseurl }}/images/Hard_disk_drive.jpg) - -Self Encrypting Disks (SED) are one layer of protection against certain threats, - but they can't be entirely trusted. The firmware on the disks is difficult to - audit and researchers has found malware in some drives. - [HDD Hacking, Sprite_tim 2014](https://spritesmods.com/?art=hddhack&page=1) - However, software disk encryption can reduce the malware threat since the - drives won't have access to cleartext data and proper setup of the IOMMU can - prevent the drive from accessing memory outside of the encrypted buffer cache. - Most SED hardware doesn't work well with S3 resume, so it is hard to use with - mobile devices (although this is an area where the Coreboot/Heads runtime might - be able to take over in the S3 resume path). - -"Replay attacks" are possible against the system even with entirely encrypted - disks. Better filesystems might help -- SGX style Merkel tree that uses the TPM - monotonic counter to prevent rollback is one option. This might not matter in - practice since the user could detect that things have reverted. Plus other - defenses should help prevent the adversary from being able to modify the entire - disk. Tools like dm-verity can be used with read-only filesystems to ensure - that only signed code is executed from the disk - [dm-verity: device-mapper block integrity checking target - Milan Broz](https://gitlab.com/cryptsetup/cryptsetup/-/wikis/DMVerity) - . - -Cleartext data should never be presented to the NIC, so it shouldn't be able to - do much exfiltration. Custom firmware like Thundergate - [Thundergate - an open source toolkit for PCI bus exploration](https://web.archive.org/web/20180329052249/http://www.thundergate.io/) - or NICssh - [Project Maux II (PDF) - Triulzi, 2008](http://www.alchemistowl.org/arrigo/Papers/Arrigo-Triulzi-PACSEC08-Project-Maux-II.pdf) - allow potentially malicious code to run on the NIC, so again it is important to - configure devices like the IOMMU to prevent random read/writes to system memory - from occurring. Where possible the write protect pins on the devices should be - hard wired to prevent software updates, although physical attackers might still - be able rewrite the firmware. - -Management Hardware ----- +A critical architectural point: the security of the entire measured boot +chain depends on the integrity of the *first* measurement -- the code +that performs the initial `extend()` into PCR0. If an attacker can modify +that initial measurement code (the bootblock), they can forge all +subsequent PCR values to match expected measurements while booting +malicious firmware. This is why Heads runs from SPI flash with hardware +write protection and why Boot Guard Measured Boot (which measures the +initial firmware descriptor into PCR0 before any mutable code runs) is +a valuable complement on platforms that support it. -![Flashing Heads on an x230 at HOPE]({{ site.baseurl }}/images/Flashing_Heads_on_an_x230_at_HOPE.jpg) - -The Intel Management Engine (ME) is unfortunately a trusted component in the - boot process as well as during special execution modes like TXT. The firmware - for it is stored in the boot ROM, but it is opaque and undocumented outside of - Intel, so we can't know what it is doing. It implements "Active Management - Technologies" (AMT) that allow remote control of the system, which represents a - fairly significant threat to security. Some projects, like Libreboot, do not - trust it at all and only support older CPUs without ME hardware. +#### File systems -In server machines there is a "Board Management Controller" (BMC) that handles - booting the system and remote console over ethernet. In order to do this it has - access to the keyboard and video of the console, as well as access to all of - the sensors and power systems on the motherboard. This firmware is typically - closed source and occasionally updated, although modern BMC are built with - Linux and share a large number of Linux vulnerabilities. If the BMC is - compromised it is in a very priviledged position to attack the host system and - exfiltrate data. Facebook has started the OpenBMC project for their servers to - allow them to have a faster patch and deploy cycle. +To be written: read-only root, [dm-verity](https://gitlab.com/cryptsetup/cryptsetup/-/wikis/DMVerity), [TPM](https://trustedcomputinggroup.org/resource/tpm-library-specification/) anti-rollback counters, signed +kernels, etc. -Threat Model -=== +### Threat Model -![]({{ site.baseurl }}/images/Threat_model.jpg) +![Threat model]({{ site.baseurl }}/images/Threat_model.jpg) This section needs to be expanded to describe different threat models for - different users. As @corcra says, "your threat model is not my threat model but - your threat model is ok". The EFF has written the Surveillance Self-Defense - guide that has a good introduction to generating threat models. The Center for + different users. As [@corcra](https://github.com/corcra) says, "your threat model is not my threat model but + your threat model is ok". The EFF has written the + [Surveillance Self-Defense](https://ssd.eff.org/) + guide that has a good introduction to generating threat models, as well as a + [threat modeling activity handout](https://www.securityeducationcompanion.org/materials/threat-modeling-activity-handout-english-spanish) + for understanding the process. The Center for Investigative Journalism has a good four part article on [threats/defences](https://web.archive.org/web/20161227232517/http://www.tcij.org/resources/guides-0/goals-threats-and-defences) , basic physical modifications, advanced modifications and [replacing the BIOS](https://web.archive.org/web/20160927161825/http://www.tcij.org:80/resources/guides-0/replacing-BIOS) . -Goals of the attacker ----- +#### Goals of the attacker * Monitor the user's communications * Exfiltrate data from running system @@ -269,8 +414,7 @@ Goals of the attacker * Masquarade as the user * Install unauthorized software -Capabilities of the attacker ----- +#### Capabilities of the attacker * Shoulder surf * Attempt phishing attacks @@ -279,9 +423,9 @@ Capabilities of the attacker * Attempt to exploit software bugs * Overtly gain temporary exterior physical access to the system * Covertly gain temporary external physical access -* Read memory from the system (DMA attack) +* Read memory from the system ([DMA attack](https://en.wikipedia.org/wiki/DMA_attack)) * Covertly gain temporary internal physical access -* Read memory from the system (cold boot attack) +* Read memory from the system ([cold boot attack](https://en.wikipedia.org/wiki/Cold_boot_attack)) * Gain long term physical access to the system * Install new firmware in devices * Install new firmware on the logic board @@ -292,11 +436,20 @@ Capabilities of the attacker * Backdoor security chips * Sign Intel ME firmware or ACM sections -Tradeoffs ----- +#### External Threats + +* Phishing +* Snooping +* Spear phishing +* Supply chain +* Corporate +* Local gov't +* National + +#### Tradeoffs * Physical modifications vs off-the-shelf hardware -* Configuring TPM, secret sharing, etc +* Configuring [TPM](https://trustedcomputinggroup.org/resource/tpm-library-specification/), secret sharing, etc * #goodbios requires non-trivial hardware mods * Heavily modified system reveals that the system is worth protecting * The opposite of Tails @@ -324,24 +477,9 @@ Extensibility vs Trusted code * Allowing arbitrary code installation creates new attack surfaces -Other stuff ----- - Storage root keys with secret sharing. -External Threats ----- - -* Phishing -* Snooping -* Spear phishing -* Supply chain -* Corporate -* Local gov't -* National - -Internal Threats ----- +### Internal Threats ![wocintech (microsoft) - 201]({{ site.baseurl }}/images/wocintechchat_25721068170.jpg) @@ -362,7 +500,7 @@ The exfil case ranges from attempts to copy data to removable media to physical proof or the counter measures sufficient to prevent access to the keys (epoxy on key parts, case intrusion switches to zero TPM secrets, etc). -Qubes can compartmentalize the various guests so that one containing secretive +[Qubes](https://www.qubes-os.org/) can compartmentalize the various guests so that one containing secretive topics can be isolated from one that is running untrusted user code. Its window manager prevents compartments from taking screen shots of other compartments and the memory isolation prevents data copying between them. @@ -380,52 +518,55 @@ Coercion shouldn't matter since the protections desired against the normal System administrators -- two key model for signing and configuring? Need to think more on this. -Physical attacks ----- - -Safes are rated in hours/minutes that a safe cracker requires to break into it. - Likewise some physical attacks can be done in a few seconds with only external - access, while others require disassembly of the device and hours of effort. - However, as Schneier says "Attacks only get better" - [New Cryptanalytic Results Against SHA-1, Scheiner 2005](https://www.schneier.com/blog/archives/2005/08/new_cryptanalyt.html) - , so time estimates for various methods are an upper bound. Likewise attacks - that are be limited to nation state adversaries today might be more practical - for average attackers in a few years time. - -An insider threat is especially difficult to counter since they have - unrestricted access to the device and can spent an arbitrary amount of time, - effort and expertise on breaking into it. Additionally, they potentially have - access to all of the keys that are not stored in non-exportable hardware (and - depending on their level of expertise they might be able to get them). - -Some threats assume that the adversary will modify the hardware, install - hardware or software measures, and return it to the owner. This is very similar - to an insider threat in that the machine will be returned to the owner and - possibly used to access private data while there might be unauthorized code - executing on the system. - -* Brief external physical access, with owner present - * Customs -* Brief external physical access, without owner present - * Classic "Evil Maid" - * Customs, in some countries -* Brief internal physical access - * Customs - * Specialized "Evil Maid", coldboot attacks -* Extended external physical access - * Checked luggage -* Extended internal physical access - * Insider threat - * TAO "Evil Maid" or checked luggage -* Unbounded internal physical access - * Theft - * Insider threat +### Enterprise Security vs Cypherpunk Security -Countermeasures -=== +Heads is not designed for "Cover" or "Concealment" + [COMSEC beyond encryption (PDF) - gruqg and rantyben, 2014](http://grugq.github.io/presentations/COMSEC%20beyond%20encryption.pdf) + -- using tools like Heads, [Qubes](https://www.qubes-os.org/) and having heavily modified laptop hardware + might provide more security than a Macbook, but might also attract more + attention than a stock machine. Qubes provides software based + Compartmentalization and Heads should provide good Confidentiality and + Integrity through [TPM](https://trustedcomputinggroup.org/resource/tpm-library-specification/) protected keys, signed read-only filesystems with + rollback prevention, etc. Depending on your threat model this might not be the + best tradeoff: Heads can help protect your system against a business + competitor, but there is no "NSA proof toolkit" that can stop a nation state + from making you have a very bad day. -Hardware ----- +It is critical to understand that not all "security" technologies serve +the same goals. **Enterprise Security** prioritizes protecting corporate +assets and often does so by granting a centralized authority (the OEM, +the IT department, a managed security provider) control over the device -- +even if that means stripping agency from the end user. [Secure Boot](https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-secure-boot) and +[Intel AMT](https://www.intel.com/content/www/us/en/architecture-and-technology/intel-active-management-technology.html) are examples: they can prevent unauthorized firmware, but they +also prevent the user from running alternative firmware and may grant +remote access to third parties. + +**Cypherpunk Security**, by contrast, prioritizes individual autonomy. It +aims to give the user -- not a vendor or government -- verifiable control +over their own device. Heads embodies this approach: the user provisions +their own [GPG](https://gnupg.org/) signing key (preferably on an external hardware token such +as a [Nitrokey](https://www.nitrokey.com/) or [Librem Key](https://puri.sm/products/librem-key/)), and all firmware and boot configuration +updates must be signed by that user-controlled key. This is fundamentally +different from Secure Boot, where the OEM controls the key hierarchy and +the user must trust that the OEM's key management practices are sound -- +which [historically they have not been](https://arstechnica.com/information-technology/2015/06/stuxnet-spawn-infected-kaspersky-using-stolen-foxconn-digital-certificates/). + +Heads repurposes [TPM](https://trustedcomputinggroup.org/resource/tpm-library-specification/) technology -- which was originally designed for +Enterprise DRM and remote attestation *against* the device owner -- and +uses it to give the owner verifiable integrity guarantees. Since Heads +controls the TPM from the very first instruction executed by the CPU +(the bootblock in SPI flash), it can use the TPM's `seal`/`unseal` and +[PCR extend](https://trustedcomputinggroup.org/resource/pc-client-specific-platform-firmware-profile-specification/) operations to protect *user* secrets, not corporate secrets. + +This distinction should inform every decision in your threat model: +technologies designed for Enterprise Security may actively undermine +Cypherpunk Security goals. When evaluating any security mechanism, +ask: who holds the keys, who benefits from the trust model, and does +it increase or decrease user autonomy? + +### Countermeasures + +#### Hardware * Case intrusion switches flush TPM * Write protect pins on flash chips @@ -433,95 +574,323 @@ Hardware * Self-encrypting disks? (S3 issues) * Epoxy in ports * Epoxy on chips +* Glitter nail polish on case screws for tamper evidence + ([use the Blink Comparison app](https://github.com/proninyaroslav/blink-comparison) + to verify screw seal photos over time) +* Tamper-evident storage: transparent container with lentil/bean + mosaic, photographed for later comparison + ([dys2p guide](https://dys2p.com/en/2021-12-tamper-evident-protection.html)) -Firmware ----- +#### Firmware Lenovo X1 Carbon -* Measured Boot into TPM PCR0 -* CoreBoot with reproducible builds +* Measured Boot into [TPM](https://trustedcomputinggroup.org/resource/tpm-library-specification/) PCR0 +* [CoreBoot](https://doc.coreboot.org/) with reproducible builds * TPM sealed drive keys * TPMTOTP to attest firmware state to user * Remote attestation of TPM state * Signed or "known good" firmware blobs -System Software ----- +#### System Software * Hypervisor based compartmentalization * Locked down compartment configuration * Encrypted compartment disk images * Two Factor auth * Biometric auth -* TRESOR to avoid coldboot +* [TRESOR](https://www1.informatik.uni-erlangen.de/tresor) to avoid coldboot * VPN tunneled enclaves -* SGX Enclaves -* TXT system config +* [SGX](https://www.intel.com/content/www/us/en/architecture-and-technology/software-guard-extensions.html) Enclaves +* [TXT](https://www.intel.com/content/www/us/en/developer/articles/technical/intel-trusted-execution-technology.html) system config + +### CPU Vulnerabilities and Microcode + +With the disclosure of the [Spectre](https://spectreattack.com/) and [Meltdown](https://meltdownattack.com/) vulnerabilities in January 2018, it became apparent that most processors manufactured since the late 1990s can potentially be compromised by attacks made possible because of [transient execution CPU vulnerabilities](https://en.wikipedia.org/wiki/Transient_execution_CPU_vulnerability). For a broader timeline of firmware and hardware security flaws, see the [firmware security flaws timeline](https://darkmentor.com/timeline.html). Modern CPUs utilize speculative execution in order to increase performance. A branch misprediction may leave observable side effects that may reveal private data to attackers using a timing attack. Future not-yet-identified vulnerabilities of this kind is likely. For users of [Qubes OS](https://www.qubes-os.org/), this class of vulnerabilities can additionally compromise the enforced isolation of virtual machines, and it is prudent to take the risks associated with these vulnerabilities into account when deciding on a platform on which to run Heads and Qubes OS. + +Since Spectre/Meltdown, researchers have disclosed a steady stream of +transient execution and microarchitectural side-channel vulnerabilities +affecting Intel platforms, many of which Heads-supported hardware may be +exposed to: + +- **2018:** [BranchScope](https://www.cs.ucr.edu/~nael/pubs/micro16.pdf) -- attacks the directional branch predictor to + infer victim branch decisions, including inside [SGX](https://www.intel.com/content/www/us/en/architecture-and-technology/software-guard-extensions.html) enclaves. +- **2019:** [Microarchitectural Data Sampling (MDS)](https://mdsattacks.com/) -- [RIDL](https://mdsattacks.com/), Fallout, + [ZombieLoad](https://zombieloadattack.com/) leak data from CPU-internal buffers. +- **2020:** [CacheOut](https://cacheoutattack.com/) ([CVE-2020-0549](https://nvd.nist.gov/vuln/detail/CVE-2020-0549)) -- bypassed Intel's MDS microcode + mitigations by recovering L1 cache evictions from leaky buffers; + [CrossTalk](https://www.vusec.net/projects/crosstalk/) ([CVE-2020-0543](https://nvd.nist.gov/vuln/detail/CVE-2020-0543)) -- demonstrated cross-core transient execution + leaks via a shared staging buffer, including [SGX](https://www.intel.com/content/www/us/en/architecture-and-technology/software-guard-extensions.html) key extraction. +- **2022:** [Branch History Injection](https://www.vusec.net/projects/bhi-spectre-bhb/) (BHI, [CVE-2022-0001](https://nvd.nist.gov/vuln/detail/CVE-2022-0001)) and + Post-Barrier RSB ([CVE-2022-26373](https://nvd.nist.gov/vuln/detail/CVE-2022-26373)). +- **2024:** [Branch Privilege Injection](https://comsec.ethz.ch/research/microarch/branch-privilege-injection) (BPRC, [CVE-2024-45332](https://nvd.nist.gov/vuln/detail/CVE-2024-45332)) -- disclosed + in [QSB-107](https://www.qubes-os.org/news/2025/05/15/qsb-107/), affecting CPUs back to 7th Gen Intel Core. +- **2025:** Multiple Intel CPU CVEs ([CVE-2025-48800](https://nvd.nist.gov/vuln/detail/CVE-2025-48800), [CVE-2025-48003](https://nvd.nist.gov/vuln/detail/CVE-2025-48003), + [CVE-2025-48804](https://nvd.nist.gov/vuln/detail/CVE-2025-48804), [CVE-2025-48818](https://nvd.nist.gov/vuln/detail/CVE-2025-48818)). + +Beyond transient execution, several recent firmware-level vulnerabilities +are directly relevant to Heads platforms: + +- **UEFI BootHole (2020, [CVE-2020-10713](https://nvd.nist.gov/vuln/detail/CVE-2020-10713)):** vulnerability in [GRUB2](https://www.gnu.org/software/grub/) allowing + Secure Boot bypass; while Heads does not use GRUB, defensive awareness of + the bootloader attack surface is relevant. +- **[BlackLotus](https://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/) UEFI bootkit (2023, [CVE-2022-21894](https://nvd.nist.gov/vuln/detail/CVE-2022-21894)):** the first in-the-wild + UEFI bootkit bypassing [Secure Boot](https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-secure-boot) on fully patched Windows 11 systems, + demonstrating that UEFI firmware trust models remain fragile. +- **[LogoFAIL](https://binarly.io/posts/From_LogoFAIL_to_LOGOFAIL_How_Image_Parsing_Flaws_Expose_UEFI_Firmware/index.html) (2023):** exploitable image parsing flaws in [UEFI](https://uefi.org/) firmware + logo display code across all major IBVs (AMI, Insyde, Phoenix), allowing + arbitrary code execution during boot -- hundreds of consumer and + enterprise devices affected. +- **[TPM 2.0 SRTM design flaw](https://www.kb.cert.org/vuls/id/782720) (2023):** attacks exploiting power management + to reset and forge Platform Configuration Registers, bypassing measured + boot on [TPM 2.0](https://trustedcomputinggroup.org/resource/tpm-library-specification/) systems. +- **Intel microcode downgrade (2019):** vulnerability in the UEFI microcode + loader allowing an attacker to downgrade CPU microcode to a vulnerable + version, thereby re-exposing patched vulnerabilities in [Boot Guard](https://www.intel.com/content/www/us/en/content-details/834810/intel-7th-generation-core-6th-generation-core-and-xeon-e3-1200-v6-families.html) ACMs, + [TXT](https://www.intel.com/content/www/us/en/developer/articles/technical/intel-trusted-execution-technology.html) SINIT modules, and [BIOS Guard](https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/secure-coding/intel-bios-guard-technology.html). +- **Intel CSME/PCH vulnerabilities:** unsigned code execution in the + [Management Engine](https://www.intel.com/content/www/us/en/support/articles/000025619/software.html) ([CVE-2017-5705](https://nvd.nist.gov/vuln/detail/CVE-2017-5705), Intel ME v11+) and [SMM](https://www.intel.com/content/www/us/en/developer/articles/technical/intel-system-management-mode.html) [TOCTOU](https://en.wikipedia.org/wiki/Time-of-check_to_time-of-use) races + ([CVE-2022-21198](https://nvd.nist.gov/vuln/detail/CVE-2022-21198)), affecting Skylake and newer platforms. + +Mitigation of these vulnerabilities is achieved through a combination of microcode updates for the CPU and software mitigation techniques. For linux systems, software mitigation includes the implementation of [retpolines](https://support.google.com/faqs/answer/7625886) and [kernel page-table isolation](https://en.wikipedia.org/wiki/Kernel_page-table_isolation). However, some of the vulnerabilities of this class cannot be effectively mitigated without updated CPU microcode. + +Heads is built as a payload for [Coreboot](https://doc.coreboot.org/), which includes the latest available microcode updates for CPUs on supported platforms. However, Intel has stated publicly they will not release further microcode updates for products they consider discontinued and unsupported. This includes processors from the Sandy Bridge and Ivy Bridge line of CPUs. Notably this means all ThinkPad models supported by Heads will most likely not receive further microcode updates to protect against future vulnerabilities of this class. A list of [current vulnerabilities](https://www.intel.com/content/www/us/en/developer/topic-technology/software-security-guidance/processors-affected-consolidated-product-cpu-model.html) and whether [microcode updates are available](https://www.intel.com/content/www/us/en/support/articles/000022396/processors.html) is provided by Intel. AMD is less affected by these vulnerabilities because speculative execution is implemented differently. + +{: .note } +**About the `EOL_` board prefix:** Boards whose CPUs have reached end-of-life for microcode updates are prefixed `EOL_` (End Of Life) in the Heads `boards/` directory. This is a visual cue that the platform will receive no further microcode fixes for newly discovered transient execution vulnerabilities. + +The deal was broken by **[QSB-107](https://www.qubes-os.org/news/2025/05/15/qsb-107/) (May 2025)** -- which disclosed Branch Privilege Injection (BPRC; CVE-2024-45332) and other branch prediction vulnerabilities. COMSEC (ETH Zürich) demonstrated that BPRC affects CPUs as far back as **7th Gen Intel Core**, but Intel itself no longer assesses those models because they've passed their ESU date. The QSB puts it bluntly: + +> *"Intel assesses whether a vulnerability affects a given CPU model only if that model still receives microcode updates. Therefore, if a given CPU model no longer receives microcode updates, one should not infer that a vulnerability does not affect that model merely because Intel does not report it as affected."* + +This confirmed that relying on Intel's microcode support lifecycle leaves a growing gap: transient execution vulnerabilities keep being discovered, but CPUs past their ESU date silently drop off Intel's assessment radar -- they're not patched, not even evaluated. + +**Important nuance -- not all 8th Gen CPUs are the same:** + +See [BOARDS_AND_TESTERS.md](https://github.com/linuxboot/heads/blob/master/doc/BOARDS_AND_TESTERS.md#per-board-eolesu-status) for the authoritative per-generation EOL/ESU status. + +**Current firmware note:** As of 2025-05, coreboot's `3rdparty/intel-microcode` was updated to the 202505 revision. However, [CircleCI](https://circleci.com/)-produced Heads images use the coreboot version at build time, which may not include the latest microcode. The OS must load the microcode update early (via initramfs) for QSB-107 mitigations to take effect -- this is especially relevant for LiveOS images that may not include the updated microcode. + +For example, `EOL_x230-maximized/` indicates the 3rd Gen Ivy Bridge CPU on that board is no longer supported by Intel. Boards without the `EOL_` prefix (e.g., `novacustom-v560tu/`) still receive microcode updates. See the table above for per-board EOL/ESU dates. + +### Mitigation on EOL Platforms + +The only reliable mitigation on platforms past their ESU date is to ensure no +secret is present in memory (trusted workflow) in parallel with untrusted +workflows: + +- Run a single trusted workflow per boot session, ideally without any secrets + remaining in memory -- for example, running [Tails](https://tails.net/) from a live CD without + providing it with any disk decryption passphrase. + - [Proper OPSEC when running Tails](https://www.anarsec.guide/posts/tails): + Tails is a live system running entirely from RAM, designed to leave no + forensic trace. However, as the anarsec guide notes: "Tails will not + protect you from human error, compromised hardware, compromised + firmware, being hacked, or certain other types of attacks." This is + precisely why Heads + Tails is a defense-in-depth strategy -- Heads + protects the firmware and hardware integrity, while Tails provides + anti-forensic operation. Use a Tails USB with a + [write-protect switch](https://www.anarsec.guide/posts/tails-best/#using-a-write-protect-switch) + to prevent a compromised session from modifying the Tails USB itself. + Minimize secret exposure duration -- reboot before switching tasks. + When in doubt, reboot. + - [Proper OPSEC for Memory use on QubesOS](https://www.anarsec.guide/posts/qubes/#appendix-opsec-for-memory-use): + [Qubes OS](https://www.qubes-os.org/) provides compartmentalization that mitigates malware, but does + *not* have anti-forensic properties -- data persists on disk. Use + disposable qubes for short-lived tasks; always consider the disk + decryption key in memory at risk. The + [Qubes OS for Anarchists](https://www.anarsec.guide/posts/qubes/) guide + recommends Qubes for everyday computing (better malware resistance) and + Tails for sensitive work (better forensics protection). See their + [comparison of when to use Tails vs Qubes OS](https://www.anarsec.guide/posts/qubes/#when-to-use-tails-vs-qubes-os). + +On systems affected by QSB-107 and lacking updated microcode, [any untrusted +application running in a qube could potentially exfiltrate sensitive memory +content at a rate of as fast as 5.6 KiB/s](https://comsec.ethz.ch/research/microarch/branch-privilege-injection). + +See **[BOARDS_AND_TESTERS.md](https://github.com/linuxboot/heads/blob/master/doc/BOARDS_AND_TESTERS.md#per-board-eolesu-status)** +for the authoritative per-board EOL/ESU status. + +Operating systems (e.g. [Qubes OS](https://www.qubes-os.org/)) can mitigate some of these vulnerabilities by other means. An example is the [SRBDS](https://www.intel.com/content/www/us/en/developer/topic-technology/software-security-guidance/processors-affected-consolidated-product-cpu-model.html) vulnerability, where the [Xen](https://xenproject.org/) hypervisor can apply a [workaround](https://seclists.org/oss-sec/2020/q2/182) to mitigate the vulnerability for Ivy Bridge CPUs, which will not receive any microcode update. It is uncertain whether such mitigations are possible in the future without microcode updates supplied from the CPU manufacturer. + +The impact on performance as a result of software and microcode mitigations vary between systems and the type of workloads involved. Compared to a system not applying any mitigation measures, a conservative estimate is that the percentage of lost performance is in the low double digit range. Furthermore, as part of mitigating the [L1TF](https://www.intel.com/content/www/us/en/developer/topic-technology/software-security-guidance/processors-affected-consolidated-product-cpu-model.html) vulnerability, Qubes OS [disables](https://www.qubes-os.org/news/2018/09/02/qsb-43/) [HyperThreading](https://www.intel.com/content/www/us/en/gaming/resources/hyper-threading.html) by default. This has a notable impact on performance in itself, effectively halving the number of cores visible to the system, but is implemented to minimize vulnerability. + +### Binary Blobs, ME, and Peripheral Firmware + +![Flashing Heads on an x230 at HOPE]({{ site.baseurl }}/images/Flashing_Heads_on_an_x230_at_HOPE.jpg) + +The [Intel Management Engine (ME)](https://www.intel.com/content/www/us/en/support/articles/000025619/software.html) is unfortunately a trusted component in the + boot process as well as during special execution modes like [TXT](https://www.intel.com/content/www/us/en/developer/articles/technical/intel-trusted-execution-technology.html). The firmware + for it is stored in the boot ROM, but it is opaque and undocumented outside of + Intel, so we can't know what it is doing. It implements "[Active Management + Technologies](https://www.intel.com/content/www/us/en/architecture-and-technology/intel-active-management-technology.html)" (AMT) that allow remote control of the system, which represents a + fairly significant threat to security. Some projects, like [Libreboot](https://libreboot.org/), do not + trust it at all and only support older CPUs without ME hardware. + +In a [re-uploaded Intel promotional video](https://www.youtube.com/watch?v=1seNMSamtxM) (originally recorded ~2012-2016), +Intel Principal Engineer Ylian Saint-Hilaire pitched AMT as a remote management + feature, describing a co-processor that remains accessible even when the computer + is off: + +> "...you can talk to this little processor even if the computer is off... +> you can access this little web server and load web pages and you can power +> up the computer, power it off, you can manage it, you can even reformat it +> remotely..." + +> "...it's kind of a little bit of a hacker software [inside the +> motherboard]... but it's a hacker software that's extremely secure and that +> only the person that's authorized to access it can access it." + +Intel's pitch -- always-on remote access, opaque firmware, and + security-by-design claims -- is precisely what makes ME a threat: an + un-auditable, network-connected co-processor with full memory access that + the owner cannot inspect or disable. + +In server machines there is a "Board Management Controller" (BMC) that handles + booting the system and remote console over ethernet. In order to do this it has + access to the keyboard and video of the console, as well as access to all of + the sensors and power systems on the motherboard. This firmware is typically + closed source and occasionally updated, although modern BMC are built with + Linux and share a large number of Linux vulnerabilities. If the BMC is + compromised it is in a very priviledged position to attack the host system and + exfiltrate data. Facebook has started the [OpenBMC](https://github.com/openbmc/openbmc) project for their servers to + allow them to have a faster patch and deploy cycle. + +#### Peripheral Firmware + +![Hard disk drive]({{ site.baseurl }}/images/Hard_disk_drive.jpg) + +Self Encrypting Disks (SED) are one layer of protection against certain threats, + but they can't be entirely trusted. The firmware on the disks is difficult to + audit and researchers has found malware in some drives. + [HDD Hacking, Sprite_tim 2014](https://spritesmods.com/?art=hddhack&page=1) + However, software disk encryption can reduce the malware threat since the + drives won't have access to cleartext data and proper setup of the IOMMU can + prevent the drive from accessing memory outside of the encrypted buffer cache. + Most SED hardware doesn't work well with S3 resume, so it is hard to use with + mobile devices (although this is an area where the Coreboot/Heads runtime might + be able to take over in the S3 resume path). + +"Replay attacks" are possible against the system even with entirely encrypted + disks. Better filesystems might help -- [SGX](https://www.intel.com/content/www/us/en/architecture-and-technology/software-guard-extensions.html) style Merkel tree that uses the [TPM](https://trustedcomputinggroup.org/resource/tpm-library-specification/) + monotonic counter to prevent rollback is one option. This might not matter in + practice since the user could detect that things have reverted. Plus other + defenses should help prevent the adversary from being able to modify the entire + disk. Tools like dm-verity can be used with read-only filesystems to ensure + that only signed code is executed from the disk + [dm-verity: device-mapper block integrity checking target - Milan Broz](https://gitlab.com/cryptsetup/cryptsetup/-/wikis/DMVerity) + . + +Cleartext data should never be presented to the NIC, so it shouldn't be able to + do much exfiltration. Custom firmware like Thundergate + [Thundergate - an open source toolkit for PCI bus exploration](https://web.archive.org/web/20180329052249/http://www.thundergate.io/) + or NICssh + [Project Maux II (PDF) - Triulzi, 2008](http://www.alchemistowl.org/arrigo/Papers/Arrigo-Triulzi-PACSEC08-Project-Maux-II.pdf) + allow potentially malicious code to run on the NIC, so again it is important to + configure devices like the IOMMU to prevent random read/writes to system memory + from occurring. Where possible the write protect pins on the devices should be + hard wired to prevent software updates, although physical attackers might still + be able rewrite the firmware. + +#### Blobs, EC Firmware, and FSP -Upgrades and Bug fixes -=== +The ThinkPad boards supported by Heads are mostly free of binary blobs, with the exception of the [Intel Management Engine](https://www.intel.com/content/www/us/en/support/articles/000025619/software.html) (which can be "neutered" or minimized) and the ethernet blob (which can be generated). CPU microcode can also technically be considered a binary blob. -One of the benefits of installing CoreBoot in place of the system's existing EFI +The Embedded Controller chip (EC) also uses its own firmware. The chip is responsible for certain system tasks not handled by the operating system, such as keyboard hotkeys, thermals, hardware toggle switches etc. It should be noted that the EC can only be updated as part of the proprietary Lenovo BIOS update. It is therefore advisable to flash the latest Lenovo BIOS prior to flashing Heads, in order to have an up-to-date EC. It is possible to make certain changes to the EC by [modifying](https://github.com/hamishcoleman/thinkpad-ec) the official Lenovo BIOS update before flashing, e.g. to allow for a classic 7-row keyboard in the X230. Coreboot/Heads will not touch the EC. + +Newer hardware platforms like the [Librem](https://puri.sm/products/) line of computers, while great care has been taken by [Purism](https://puri.sm/) to minimize blobs, still contain the closed-source Intel [FSP](https://www.intel.com/content/www/us/en/developer/topic-technology/firmware-support-package/overview.html) (Firmware Support Package, needed to initialise memory/silicon). However, the CPUs used in these computers are newer, and thus will perceivably receive microcode updates for some time. They generally also allow for more RAM and arguably more modern hardware in general. + +When choosing a platform for Heads/[Qubes OS](https://www.qubes-os.org/), the user must make an informed decision on whether the presence of binary blobs and potential security benefits in future microcode updates outweigh the desirability of maximum control over the firmware on the hardware platform. In addition, the user must take into account the limitations on hardware performance by the various supported boards, and whether the potential increase in performance afforded by a more recent CPU and additional RAM is desirable to compensate for performance reductions as a result of mitigating these vulnerabilities. + +### Upgrades and Bug Fixes + +One of the benefits of installing [CoreBoot](https://doc.coreboot.org/) in place of the system's existing EFI firmware is that bug fixes can be applied more quickly. Normally EFI bugs are - fixed by Intel in EDK2, but there is nothing that forces vendors to pull the + fixed by Intel in [EDK2](https://github.com/tianocore/edk2), but there is nothing that forces vendors to pull the patches, nor do they often publish new firmware images for every platform that they have sold [Discussed in more detail in Thunderstrike 2, Hudson 2015](https://trmm.net/Thunderstrike2_details) . Since the firmware is largely closed source, end users aren't able to fix the bugs on their own, so their older systems remain vulnerable. -Write-protecting the BIOS chip (Advanced) -=== +#### Write-protecting the BIOS Chip (Advanced) **!!!! WARNING !!!!** This is for advanced users only. Many of these commands have not been tested and it is uncertain what will happen if there is an error. However, many of the countermeasures applied to harden the system against - physical attacks also make it hard to upgade the firmware. If the boot ROM's + physical attacks also make it hard to upgrade the firmware. If the boot ROM's write protect pins have been hard wired, there is nothing software can do to - update the ROM image that is marked as read-only with the BP bits. The Coreboot + update the ROM image that is marked as read-only with the BP bits. The [Coreboot](https://doc.coreboot.org/) ramstage and the Heads Linux kernel/initrd can be updated if they are not covered by BP, so hopefully the romstage is small enough that it is "bug free". Additionally, many of the secrets protected by the TPM are locked to the PCR values that result from hashing the firmware, so procedures for extracting and replacing the keys are necessary. -More information related to this can be found in [Replacing the BIOS](https://web.archive.org/web/20160927161825/http://www.tcij.org:80/resources/guides-0/replacing-BIOS) +More information related to this can be found in [Replacing the BIOS](https://web.archive.org/web/20160927161825/http://www.tcij.org:80/resources/guides-0/replacing-BIOS). +For SPI programmer selection guidance, see the [Flashing guides](http://osresearch.net/Flashing-guides). More work is necessary in this area. -A note on Cover, Concealment and Compartmentalization -=== - -Heads is not designed for "Cover" or "Concealment" - [COMSEC beyond encryption (PDF) - gruqg and rantyben, 2014](http://grugq.github.io/presentations/COMSEC%20beyond%20encryption.pdf) - -- using tools like Heads, Qubes and having heavily modified laptop hardware - might provide more security than a Macbook, but might also attract more - attention than a stock machine. Qubes provides software based - Compartmentalization and Heads should provide good Confidentiality and - Integrity through TPM protected keys, signed read-only filesystems with - rollback prevention, etc. Depending on your threat model this might not be the - best tradeoff: Heads can help protect your system against a business - competitor, but there is no "NSA proof toolkit" that can stop a nation state - from making you have a very bad day. - -Binary blobs, microcode updates and transient execution vulnerabilities -=== -With the disclosure of the Spectre and Meltdown vulnerabilities in January 2018, it became apparent that most processors manufactured since the late 1990s can potentially be compromised by attacks made possible because of [transient execution CPU vulnerabilities](https://en.wikipedia.org/wiki/Transient_execution_CPU_vulnerability). Modern CPUs utilize speculative execution in order to increase performance. A branch misprediction may leave observable side effects that may reveal private data to attackers using a timing attack. Future not-yet-identified vulnerabilities of this kind is likely. For users of Qubes OS, this class of vulnerabilities can additionally compromise the enforced isolation of virtual machines, and it is prudent to take the risks associated with these vulnerabilities into account when deciding on a platform on which to run Heads and Qubes OS. - -Mitigation of these vulnerabilities is achieved through a combination of microcode updates for the CPU and software mitigation techniques. For linux systems, software mitigation includes the implementation of retpolines and kernel page-table isolation. However, some of the vulnerabilities of this class cannot be effectively mitigated without updated CPU microcode. - -Heads is built as a payload for Coreboot, which includes the latest available microcode updates for CPUs on supported platforms. However, Intel has stated publicly they will not release further microcode updates for products they consider discontinued and unsupported. This includes processors from the Sandy Bridge and Ivy Bridge line of CPUs. Notably this means all ThinkPad models supported by Heads will most likely not receive further microcode updates to protect against future vulnerabilities of this class. A list of [current vulnerabilities](https://software.intel.com/content/www/us/en/develop/topics/software-security-guidance/processors-affected-consolidated-product-cpu-model.html) and whether [microcode updates are available](https://www.intel.com/content/www/us/en/support/articles/000022396/processors.html) is provided by Intel. AMD is less affected by these vulnerabilities because speculative execution is implemented differently. - -Operating systems (e.g. Qubes OS) can mitigate some of these vulnerabilities by other means. An example is the SRBDS vulnerability, where the Xen hypervisor can apply a [workaround](https://seclists.org/oss-sec/2020/q2/182) to mitigate the vulnerability for Ivy Bridge CPUs, which will not receive any microcode update. It is uncertain whether such mitigations are possible in the future without microcode updates supplied from the CPU manufacturer. - -The impact on performance as a result of software and microcode mitigations vary between systems and the type of workloads involved. Compared to a system not applying any mitigation measures, a conservative estimate is that the percentage of lost performance is in the low double digit range. Furthermore, as part of mitigating the L1TF vulnerability, Qubes OS [disables](https://www.qubes-os.org/news/2018/09/02/qsb-43/) HyperThreading by default. This has a notable impact on performance in itself, effectively halving the number of cores visible to the system, but is implemented to minimize vulnerability. - -The ThinkPad boards supported by Heads are mostly free of binary blobs, with the exception of the Intel Management Engine (which can be "neutered" or minimized) and the ethernet blob (which can be generated). CPU microcode can also technically be considered a binary blob. - -The Embedded Controller chip (EC) also uses its own firmare. The chip is responsible for certain system tasks not handled by the operating system, such as keyboard hotkeys, thermals, hardware toggle switches etc. It should be noted that the EC can only be updated as part of the propietary Lenovo BIOS update. It is therefore advisable to flash the latest Lenovo BIOS prior to flashing Heads, in order to have an up-to-date EC. It is possible to make certain changes to the EC by [modifying](https://github.com/hamishcoleman/thinkpad-ec) the official Lenovo BIOS update before flashing, e.g. to allow for a classic 7-row keyboard in the X230. Coreboot/Heads will not touch the EC. - -Newer hardware platforms like the Librem line of computers, while great care has been taken by Purism to minimize blobs, still contain the closed-source Intel FSP (Firmware Support Package, needed to initialise memory/silicon). However, the CPUs used in these computers are newer, and thus will perceivably receive microcode updates for some time. They generally also allow for more RAM and arguably more modern hardware in general. - -When choosing a platform for Heads/Qubes OS, the user must make an informed decision on whether the presence of binary blobs and potential security benefits in future microcode updates outweigh the desirability of maximum control over the firmware on the hardware platform. In addition, the user must take into account the limitations on hardware performance by the various supported boards, and whether the potential increase in performance afforded by a more recent CPU and additional RAM is desirable to compensate for performance reductions as a result of mitigating these vulnerabilities. +### Further Learning + +For training on firmware security, TPM concepts, and trusted computing, see +[Open Security Training 2 (OST2)](https://ost2.fyi/). OST2 provides free, +open-source, self-paced cybersecurity classes. Their +[Firmware Security learning path](https://ost2.fyi/Firmware-Security.html) +covers BIOS/UEFI architecture, TPM specification internals, SMM attacks, +measured boot, and platform security analysis -- topics directly relevant +to understanding the threats Heads defends against. All course materials +are released under open-source licenses ([Creative Commons](https://creativecommons.org/)). + +Additional resources referenced throughout this document: + +- [EFF Surveillance Self-Defense](https://ssd.eff.org/) guide and + [threat modeling activity handout](https://www.securityeducationcompanion.org/materials/threat-modeling-activity-handout-english-spanish) +- [Firmware security flaws timeline (darkmentor.com)](https://darkmentor.com/timeline.html) +- [EFF threat modeling activity handout](https://www.securityeducationcompanion.org/materials/threat-modeling-activity-handout-english-spanish) +- [Center for Investigative Journalism: threats and defences](https://web.archive.org/web/20161227232517/http://www.tcij.org/resources/guides-0/goals-threats-and-defences) +- [TCIJ: Replacing the BIOS](https://web.archive.org/web/20160927161825/http://www.tcij.org:80/resources/guides-0/replacing-BIOS) +- [anarsec tamper-evident guide](https://www.anarsec.guide/posts/tamper/) +- [anarsec: Proper OPSEC when running Tails](https://www.anarsec.guide/posts/tails) +- [anarsec: Qubes OS for Anarchists](https://www.anarsec.guide/posts/qubes/) +- [COMSEC beyond encryption (PDF) - gruqg and rantyben, 2014](http://grugq.github.io/presentations/COMSEC%20beyond%20encryption.pdf) + +### References + +Coreboot and Heads technical references: + +- [Coreboot GPIO lock patch series](https://review.coreboot.org/q/topic:%22intel_gpio_lock%22) + (patches [#90884](https://review.coreboot.org/c/coreboot/+/90884), + [#90885](https://review.coreboot.org/c/coreboot/+/90885), + [#93324](https://review.coreboot.org/c/coreboot/+/93324), + [#93422](https://review.coreboot.org/c/coreboot/+/93422)) +- [Coreboot ticket #576](https://ticket.coreboot.org/issues/576) -- TPM GPIO reset vulnerability +- [Intel Boot Guard analysis (Ermolov)](https://github.com/flothrone/bootguard) +- [Intel doc 834810 (7th/6th Gen Core and Xeon E3-1200 v6 families datasheet)](https://www.intel.com/content/www/us/en/content-details/834810/intel-7th-generation-core-6th-generation-core-and-xeon-e3-1200-v6-families.html) +- [Intel consolidated list of vulnerabilities by CPU model](https://www.intel.com/content/www/us/en/developer/topic-technology/software-security-guidance/processors-affected-consolidated-product-cpu-model.html) +- [Intel microcode update availability](https://www.intel.com/content/www/us/en/support/articles/000022396/processors.html) + +TCG and TPM specifications: + +- [TPM Library Specification (TCG)](https://trustedcomputinggroup.org/resource/tpm-library-specification/) +- [PC Client Platform Firmware Profile Specification (TCG)](https://trustedcomputinggroup.org/resource/pc-client-specific-platform-firmware-profile-specification/) +- [TPM 2.0 SRTM design flaw (VU#782720)](https://www.kb.cert.org/vuls/id/782720) + +Heads project reference documents: + +- [TPM GPIO Reset Vulnerability](https://github.com/linuxboot/heads/blob/master/doc/TPM_GPIO_Reset_Vulnerability.md) +- [BOARDS_AND_TESTERS.md -- Per-board EOL/ESU status](https://github.com/linuxboot/heads/blob/master/doc/BOARDS_AND_TESTERS.md#per-board-eolesu-status) +- [TPM GPIO reset bypass analysis (mkukri.xyz)](https://mkukri.xyz/2024/06/01/tpm-gpio-fail.html) +- [State considered harmful (Rutkowska 2015)]({{ site.baseurl }}/PDFs/state_harmful.pdf) + +Key vulnerability disclosures: + +- [QSB-107 (Qubes OS, May 2025)](https://www.qubes-os.org/news/2025/05/15/qsb-107/) +- [Branch Privilege Injection (BPRC, ETH Zurich COMSEC)](https://comsec.ethz.ch/research/microarch/branch-privilege-injection) +- [Thunderstrike (Hudson 2014)](https://trmm.net/Thunderstrike) +- [Thunderstrike 2 (Hudson 2015)](https://trmm.net/Thunderstrike2_details) +- [Evil Maid attack (Rutkowska 2009)](https://theinvisiblethings.blogspot.com/2009/10/evil-maid-goes-after-truecrypt.html) +- [Anti Evil Maid 2 Turbo Edition (Garrett 2015)](https://mjg59.dreamwidth.org/35742.html) +- [Beyond anti evil maid (32c3)](https://media.ccc.de/v/32c3-7343-beyond_anti_evil_maid) diff --git a/About/Keys.md b/About/Keys.md index 01db469..f7f54df 100644 --- a/About/Keys.md +++ b/About/Keys.md @@ -8,6 +8,9 @@ parent: About ## Keys and passwords in Heads +{: .note } +See also: [doc/keys.md](https://github.com/linuxboot/heads/blob/master/doc/keys.md) for recommended passphrase lengths per secret. + There are "too many secrets" involved in booting a Heads system. Luckily most of them are stored in hardware and only a few need to be memorized by the users. This page documents their usage and the risks if an attacker can diff --git a/Installing-and-Configuring/Flashing-Guides/SPI-Programmer-Best-Practices.md b/Installing-and-Configuring/Flashing-Guides/SPI-Programmer-Best-Practices.md index aec4e15..4bdbb98 100644 --- a/Installing-and-Configuring/Flashing-Guides/SPI-Programmer-Best-Practices.md +++ b/Installing-and-Configuring/Flashing-Guides/SPI-Programmer-Best-Practices.md @@ -15,194 +15,129 @@ grand_parent: Installing and configuring {: .text-delta } 1. TOC {:toc} - + -This guide provides essential information for safely flashing SPI chips using external programmers, with recommendations based on extensive community testing and feedback. - -> **Note:** This page is organised for both **beginners** and **advanced users**. Beginners should follow the **Quick Start** steps below and the *Critical Safety Warning*; advanced content is collapsed in **Advanced** sections. +This is the authoritative reference for safely flashing SPI chips with external programmers. Every board-specific flashing guide links here -- read it before you touch any hardware. ## TL;DR -A short comparison of recommended programmers for quick decision-making. - -| Programmer | Best for | Voltage | Cost | -|------------|----------|---------:|------:| -| Tigard | Frequent flashing, debugging | 1.8V/3.3V/5V | $67-89 | -| CH347F | Budget but fast; adjustable VIO | 1.8V–3.3V (VIO) | $5-15 | -| CH341A rev1.6+ | Occasional flashing, budget | 1.8V/3.3V (selector) | $5-15 | -| Raspberry Pi Pico | DIY / low-cost | 3.3V only | $4-10 | - -**Quick reminder:** Always make at least two verified full-chip backups before any write operation. - -> **Quick Start — Safe minimal steps (Beginners):** -> -> 1. **Power off & remove all power sources** (batteries, AC). Wait 30s. If you cannot, stop. -> 2. **Confirm clip orientation & pin 1** (see SOIC8 clip orientation image) and ensure a Pomona‑style clip. -> 3. **Take a full chip backup and verify it** before doing any writes. -> 4. **Only after backups verify**, write firmware and verify the write. -> -```bash -# Detect and read a backup (replace placeholders) -sudo flashrom --programmer [programmer] --read backup.bin --chip "[chip_model]" -hexdump -C backup.bin | head -20 -sudo flashrom --programmer [programmer] --verify backup.bin --chip "[chip_model]" -# Write (ONLY after you have verified backups): -sudo flashrom --programmer [programmer] --chip "[chip_model]" --write firmware.rom -``` -> **If unsure, STOP and ask for help or measure the chip VCC with a multimeter.** +| Programmer | Best for | Voltage | Speed (16MB read) | Cost | +|------------|----------|---------|-------------------:|------:| +| Tigard | Frequent flashing, debugging | 1.8V / 3.3V / 5V | ~42s | $67-89 | +| CH347F | Budget but fast; adjustable VIO | 1.8V-3.3V (VIO) | ~60s (or ~4s at 60MHz) | $5-15 | +| CH341A rev1.6+ | Occasional flashing, budget | 1.8V / 3.3V (selector) | ~240s | $5-15 | +| [Raspberry Pi Pico](https://www.raspberrypi.com/products/raspberry-pi-pico/) | DIY / low-cost | 3.3V only | ~30s | $4-10 | +**Before you start:** always make two verified full-chip backups to separate locations. Without them, recovery is impossible and we cannot help you. +**Quick start (safe minimal steps):** +1. **Power off** -- remove all batteries (including CMOS), disconnect AC, wait 30s. +2. **Confirm clip orientation** -- match pin 1 (dot) on chip to red wire on [Pomona 5250](https://www.pomonaelectronics.com/products/test-clips/soic-clip-8-pin) clip. +3. **Backup and verify** -- read the full chip and verify the dump before any writes. +4. **Flash** -- only after verified backups. See [Backup & Verify](#backup--verify) and [Flashing](#flashing-new-firmware) below. -## ⚠️ Critical Safety Warning +> **If unsure, STOP. Ask for help or measure the chip VCC with a multimeter.** -**ALWAYS disconnect all power sources before flashing:** -- Remove all batteries (internal and external), including CMOS -- Disconnect AC adapter -- Wait 30 seconds for capacitors to discharge +## ⚠️ Critical Safety -**Never connect or disconnect the clip while the programmer is powered on.** This can damage your motherboard or SPI chip. +### Power Disconnection -**EC note:** If your board requires EC updates or vendor-specific EC customizations (keyboard remaps, battery whitelists, power/thermal behaviour), apply those changes from the vendor BIOS prior to an initial Heads flash. See the **EC firmware & customizations** section in the [Prerequisites]({{ site.baseurl }}/Prerequisites) for details and workflow guidance. - -## Recommended Programmers (in order of preference) - -Based on extensive community testing and feedback, here are the recommended SPI programmers: - -A short comparative read-time summary (observed community read times): +**Always disconnect all power sources before attaching the clip:** +- Remove batteries (internal, external, and CMOS) +- Disconnect AC adapter +- Wait 30 seconds for capacitors to discharge +- **Never connect or disconnect the clip while the programmer is powered on** -- this can damage your motherboard or SPI chip. -| Programmer | Typical read time (8MB / 16MB) | -|------------|-------------------------------:| -| Tigard | ~21s / ~42s | -| CH347F | ~30s / ~60s | -| CH341A rev1.6+ | ~120s / ~240s | -| Raspberry Pi Pico | ~15s / ~30s | +### Voltage -Benchmarks and detailed per-programmer timing data are available in issue #120 for those who want to dig deeper. +**Guessing voltage can destroy chips.** If you cannot identify the chip or measure its VCC with a multimeter, do not attempt in-system programming -- remove the chip or ask for help. -### Tigard (Recommended) -- **Cost**: $67-89 USD -- **Typical read time**: ~21 seconds for 8MB chip, ~42 seconds for 16MB chip (observed at Tigard's recommended SPI settings) -- **SPI clock notes**: Tigard supports VIO and user-selectable SPI clocks; speed and stability depend on chosen SPI clock. -- **Voltage**: 1.8V, 3.3V, 5V, external target voltage -- **Protocols**: SPI, I2C, JTAG, SWD, UART -- **Additional features**: Logic analyzer, USB debugging support -- **Reliability**: Excellent (4/4 success rate in community testing) -- **Best for**: Development, debugging, frequent flashing, new users +- Prefer a programmer with reliable voltage control (Tigard, CH347F with VIO, or CH341A rev1.6+ with physical selector). +- Match voltage to the chip's datasheet spec, not to "what seems to work." +- 1.8V chips require a programmer with explicit 1.8V support -- Tigard or CH347F with VIO. Do not use 3.3V-only programmers (Pico, CH347T) for 1.8V targets. -**Note:** The Tigard's SPI header is laid out to match the pin orientation of a standard 8‑pin SPI flash chip, making it easy to attach a Pomona‑style SOIC clip reliably. +### Workspace -**Where to buy**: [Crowd Supply](https://www.crowdsupply.com/securinghw/tigard) +- Use an anti-static wrist strap and mat. +- Work under good lighting with magnification available. +- Have isopropyl alcohol and flux handy for cleaning contacts. -### CH347F (Preferred CH347 variant) -- **Cost**: $5-15 USD -- **Typical read time**: *depends on SPI clock* — e.g., ~30s for 16MB at modest clocks; **example:** CH347F reading a GD25LQ128E (16 MiB) at **60 MHz** observed **~4 s** read time (community measurement). -- **Voltage / VIO (I/O voltage reference / selector)**: **CH347F** modules commonly provide adjustable I/O voltage (via a physical selector switch or exposed VIO pin), supporting ≈1.8–3.3 V and typically exposing 5V-tolerant inputs. **CH347T** variants are commonly 3.3V-only. Always verify the specific module’s documentation or seller listing and look for an explicit VIO pin or voltage selector switch before using it with 1.8V chips. -- **Protocols**: SPI, I2C, JTAG (depending on module) -- **SPI clock**: Default with `flashrom` is commonly **15 MHz** (CH347); the clock can be increased (e.g., `--spispeed` in `flashrom`) up to **60 MHz** on capable modules. Higher stable SPI clocks yield near-linear speed improvements; unstable clocks require reducing the clock for reliability. -- **Best for**: Budget-conscious users who need higher speed and **adjustable VIO**; verify the seller/module exposes the CH347**F** variant or VIO setting and read the module documentation before purchasing. +### EC Firmware -Notes & sources: -- [CH347 datasheet / download](https://www.wch-ic.com/downloads/CH347DS1_PDF.html) 🔗 -- [Review & schematic analysis: OneTransistor CH347 review](https://www.onetransistor.eu/2024/09/ch347t-programmer-schematic.html) 🔗 -- [Community measurements and discussion: issue #120](https://github.com/linuxboot/heads-wiki/issues/120) 🔗 +If your board requires vendor-specific EC customizations (keyboard remaps, battery whitelists, power/thermal behaviour), apply those from the vendor BIOS before your first Heads flash. See [Prerequisites]({{ site.baseurl }}/Prerequisites). -**Safety:** Always confirm the module's VIO (I/O voltage reference / selector) capability for 1.8V chips. **CH347F** modules that provide an adjustable I/O voltage via a selector switch or exposed VIO pin can be configured for 1.8V or 3.3V operation and—when the module documentation indicates 5V-tolerant inputs—do **not** require an external level shifter. If a module lacks an explicit selector/VIO pin or the documentation is unclear, use an external level shifter or prefer a programmer with explicit voltage control (for example, **Tigard** or **CH341A rev1.6+** with a physical selector). +## Tool Interchangeability -### CH341A Rev 1.6+ (Budget option with voltage selector) -- **Cost**: $5-15 USD -- **Typical read time**: ~120 seconds for 8MB chip (~240s for 16MB) (community measurement — see issue #120 for write/verify timings) -- **Voltage**: 1.8V, 2.5V, 3.3V, 5V (selectable via switch) -- **Protocols**: SPI, I2C -- **Reliability**: Good when used correctly -- **Best for**: Occasional flashing, budget-conscious users +Board-specific guides use these placeholders in command examples: -**⚠️ Important:** **Only use CH341A rev 1.6+ that explicitly provides a physical voltage selector or a regulator.** Older CH341A/CH341-style modules frequently output 5V and can permanently damage 3.3V flash chips. +- **`[flasher]`** -- `flashrom` or [`flashprog`](https://flashprog.org/). These tools are interchangeable; most commands work identically in both. Install whichever your distro packages (`apt install flashrom` or equivalent). +- **`[programmer]`** -- your SPI programmer type. Common values: `ch341a_spi`, `ch347_spi`, `ft2232_spi:type=2232H,port=B,divisor=4`, `serprog:/dev/ttyACM0`. See [Connection Examples](#connection-examples) for the full programmer strings. -**Visual identification (CH341A v1.6+ identification):** Look for a physical voltage selector switch or a regulator circuit; also inspect for extra components near the power pins. ![CH341A v1.6+ identification](https://github.com/linuxboot/heads-wiki/assets/827570/1b2621f6-978e-4b75-9c32-30647f741b09) +Replace placeholders with your actual values. Your board's specific flashing guide has board-specific commands (chip model, ROM path, dual-chip procedures) that use these placeholders. +## Recommended Programmers -**Where to buy**: -- [3mdeb Kit](https://shop.3mdeb.com/shop/modules/ch341a-flash-bios-usb-programmer-kit-soic8-sop8/) -- [Novacustom Kit](https://novacustom.com/product/modded-ch341a-bios-firmware-programmer-3v/) +Community-tested, ordered by preference. See [issue #120](https://github.com/linuxboot/heads-wiki/issues/120) for detailed benchmarks. -#### CH341A visual identification — do not buy generic black modules +### Tigard (recommended) -CH341-family devices vary a lot in quality and safety. Before buying a CH341 module, inspect it carefully. The safe CH341A rev 1.6+ models have a voltage selector or a dedicated regulator circuit; older generic black CH341 modules often drive 5V and can destroy 3.3V flash chips. Prefer **Pomona 5250** style SOIC clips for SOIC packages; do not rely on cheap generic clips that may slip or have poor contacts. +- **Cost:** $67-89 | **Voltage:** 1.8V, 3.3V, 5V, external target voltage +- **Protocols:** SPI, I2C, JTAG, SWD, UART +- **Speed:** ~21s (8MB), ~42s (16MB) at default SPI settings; tunable via `divisor` +- **Reliability:** Excellent (4/4 success in community testing) +- **Best for:** Development, debugging, frequent flashing, new users -> Quick reference: See the CH341A section above for recommended CH341A models (rev 1.6+). +The Tigard's SPI header matches standard SOIC8 chip pinout, making it easy to attach a [Pomona 5250](https://www.pomonaelectronics.com/products/test-clips/soic-clip-8-pin) clip. Also includes logic analyzer and USB debugging. -**Quick checklist** -- Look for a physical voltage selector (1.8V/3.3V/5V) or a regulator circuit near power pins. -- If it looks like the generic black unit above (no selector/regulator), **do not buy it**. -- Prefer Tigard or CH347F for safety; CH341A rev 1.6+ with selector is acceptable if you verify the VIO. +**Buy:** [Crowd Supply](https://www.crowdsupply.com/securinghw/tigard) -**Optimization tips (CH341A)** -- Ensure a clean power supply and a short, good-quality USB cable. -- Keep the programmer cool during long operations to prevent voltage drift or instability. -- If verification fails, try a different USB cable or power source before retrying. +### CH347F (preferred budget) -### Raspberry Pi Pico (DIY option) -- **Cost**: $4-10 USD -- **Typical read time**: ~30 seconds for 16MB chip (see issue #120 for write/verify timings) -- **Voltage**: 3.3V (configurable via firmware) -- **Protocols**: SPI (via serprog firmware) -- **Reliability**: High -- **Best for**: DIY enthusiasts, custom setups +- **Cost:** $5-15 | **Voltage:** Adjustable VIO ~1.8-3.3V (physical selector or exposed VIO pin); typically 5V-tolerant inputs +- **Protocols:** SPI, I2C, JTAG (module-dependent) +- **Speed:** Default ~15 MHz SPI clock; up to 60 MHz on capable modules. At 60 MHz a 16MB chip reads in ~4s. +- **Best for:** Budget users who need speed and adjustable VIO -*Raspberry Pi Pico wiring example (Thanks @Thrilleratplay) for SPI programming. Ensure correct wiring and 3.3V operation before powering the target board.* +**Critical:** Verify the module is a **CH347F** variant with VIO support. CH347T variants are 3.3V-only. Check seller documentation for a voltage selector switch or VIO pin before purchasing. If unclear, use Tigard or CH341A rev1.6+ instead. -![SOIC8 clip orientation](https://gist.githubusercontent.com/Thrilleratplay/60dff7cf849de5bdb84d91cabbd4fcfd/raw/6dcfa783230cdbfa7548033ed4144546492a26cd/soic8_pinout.svg) +**References:** [CH347 datasheet](https://www.wch-ic.com/downloads/CH347DS1_PDF.html) | [OneTransistor review](https://www.onetransistor.eu/2024/09/ch347t-programmer-schematic.html) -**Wiring tips**: -- Connect VCC (3.3V) from the Pico to the target's VCC/VIO, and GND to GND. -- Match MOSI/MISO/SCLK to the corresponding flash chip pins; use the Pomona clip orientation or board silks for pin-1. -- Use short jumper wires and confirm orientation with magnification; always verify voltage with a multimeter before writing. -- For boards needing 1.8V operation, use a programmer with proper VIO support (Tigard or CH347F) rather than a Pico (3.3V only). +### CH341A Rev 1.6+ (budget, occasional use) +- **Cost:** $5-15 | **Voltage:** 1.8V, 2.5V, 3.3V, 5V (physical selector switch) +- **Protocols:** SPI, I2C +- **Speed:** ~120s (8MB), ~240s (16MB); no user-adjustable SPI clock +- **Best for:** Occasional flashing, budget users who verify voltage +**⚠️ Only use rev 1.6+ modules with a physical voltage selector or regulator circuit.** Older generic black CH341 modules output 5V and will destroy 3.3V chips. -## Essential Safety Procedures +![CH341A v1.6+ identification](https://github.com/linuxboot/heads-wiki/assets/827570/1b2621f6-978e-4b75-9c32-30647f741b09) -### Before Starting -1. **Power disconnection checklist**: - - [ ] Remove all batteries (internal and external), including CMOS - - [ ] Disconnect AC adapter - - [ ] Wait 30 seconds for capacitors to discharge +**Quick checklist:** Look for a voltage selector switch (1.8V/3.3V/5V) or regulator near power pins. If it looks like a generic black module without these, **do not buy it.** -2. **Workspace preparation**: - - Use anti-static wrist strap - - Work on anti-static mat - - Ensure good lighting - - Have magnifying glass available +**Buy:** [3mdeb Kit](https://shop.3mdeb.com/shop/modules/ch341a-flash-bios-usb-programmer-kit-soic8-sop8/) | [Novacustom Kit](https://novacustom.com/product/modded-ch341a-bios-firmware-programmer-3v/) -### Equipment checklist (for flashing) -- **Programmer**: Tigard (recommended). Budget: **CH347F** (preferred budget option with adjustable VIO) or **CH341A rev1.6+** (with physical selector) for basic flashing — always verify the module's VIO/voltage capability. -- **Clip**: Pomona 5250 (recommended) for SOIC chips — high quality, better contact. -- **WSON probe / spring-loaded adapter** for WSON packages (use with an alignment guider or jig). -- **Jumper leads** and a short USB cable (use short, good-quality wires). -- **Second computer** with `flashrom` installed (Linux recommended) to run the programmer. -- **Small tools & cleaning**: magnifier/microscope, isopropyl alcohol, flux, screwdrivers, spudger. -- **Sanity tools**: `hexdump`, `diff`, and basic Unix tools to inspect and compare dumps. +### [Raspberry Pi Pico](https://www.raspberrypi.com/products/raspberry-pi-pico/) (DIY) -**Extremely important — backups:** -Make and verify multiple full‑chip backups, and store copies in a secure, separate location. If anything goes wrong or you need to restore stock firmware, these backups are required; if they are lost or corrupted recovery may be impossible and maintainers cannot help you. +- **Cost:** $4-10 | **Voltage:** 3.3V only +- **Protocols:** SPI (via [serprog](https://www.flashrom.org/serprog) firmware) +- **Speed:** ~30s (16MB) +- **Reliability:** High +- **Best for:** DIY enthusiasts, 3.3V-only workflows -### Voltage Selection Guidelines (beginner-friendly) -- **Stop if unsure**: If you cannot identify the chip or measure its VCC, do **not** perform in‑place programming — ask for help or remove the chip for external programming. ⚠️ -- **Use a safe programmer**: Prefer a programmer with reliable voltage control. Examples: **Tigard** (recommended), **CH347F** (preferred budget option with a physical voltage selector or exposed VIO pin), **CH341A rev1.6+** (budget with 1.8V selector). 🔧 -- **Power checklist (always)**: Remove batteries, disconnect AC adapter, and (if comfortable) disconnect the CMOS battery before attaching the clip. 🔌 -- **If you can identify the chip**: Follow the chip datasheet for the correct VCC. If you can safely measure the chip’s VCC with a multimeter, use that voltage. +Requires [serprog](https://www.flashrom.org/serprog)-capable firmware flashed to the Pico. Confirm device node (e.g., `/dev/ttyACM0`). **Do not use for 1.8V chips** -- prefer Tigard or CH347F. -> Tip: Guessing voltages (e.g., "try 1.8V then 3.3V") can damage some chips. If you are not comfortable identifying/measuring VCC, stop and ask for help. +![SOIC8 clip orientation](https://gist.githubusercontent.com/Thrilleratplay/60dff7cf849de5bdb84d91cabbd4fcfd/raw/6dcfa783230cdbfa7548033ed4144546492a26cd/soic8_pinout.svg) +**Wiring:** VCC (3.3V) to target VCC, GND to GND, MOSI/MISO/SCLK to corresponding flash chip pins. Use short jumper wires, confirm orientation with magnification, and verify voltage with a multimeter before writing. +## Physical Connection -### Chip detection (overview) -## SPI Chip Pin Mapping (SOIC8) +### SPI Chip Pin Mapping (SOIC8) ``` -Chip Pin Layout (top view, dot indicates pin 1): +Chip Pin Layout (top view, dot / notch = pin 1): ┌─────────────┐ │ 1 ● 8 │ │ 2 7 │ @@ -210,205 +145,171 @@ Chip Pin Layout (top view, dot indicates pin 1): │ 4 5 │ └─────────────┘ -Pin Functions: -1 - CS / CS# (Chip Select) -2 - SO / MISO (Serial Data Output) -3 - WP# / N/C (Write Protect) -4 - GND (Ground) -5 - SI / MOSI (Serial Data Input) -6 - SCLK / CLK (Clock) -7 - HOLD# / N/C (Hold) -8 - VCC (Power) +1 - CS / CS# 5 - SI / MOSI +2 - SO / MISO 6 - SCLK / CLK +3 - WP# 7 - HOLD# +4 - GND 8 - VCC ``` -### Wiring Color Code Reference (from community testing) +### Wiring Color Reference + +Tested mapping for [Pomona 5250](https://www.pomonaelectronics.com/products/test-clips/soic-clip-8-pin) clip and CH341A-style programmers: + +| Chip Pin | Pomona Clip | Function | Wire Color | Programmer Header | +|:--------:|:-----------:|:--------:|:----------:|:-----------------:| +| Pin 1 (dot) | Pin 1 (red dot) | CS | Red | 25XX / CS | +| Pin 2 | Pin 2 | SO/MISO | Blue | DO / MISO | +| Pin 3 | Pin 3 | WP# | Brown | NC | +| Pin 4 | Pin 4 | GND | Black | GND | +| Pin 5 | Pin 5 | SI/MOSI | Purple | DI / MOSI | +| Pin 6 | Pin 6 | SCLK | Orange | CLK | +| Pin 7 | Pin 7 | HOLD# | White | NC | +| Pin 8 | Pin 8 | VCC | Red | VCC | -When using custom wiring with color-coded cables, this mapping has been tested: +**Always verify pin 1 orientation** by locating the dot or notch on the chip. Red wire to pin 1. -| SPI Chip Pin | Pomona Clip | Function | Wire Color | CH341A/Programmer | -|:------------:|:-----------:|:--------:|:----------:|:-----------------:| -| Pin 1 (dot) | Pin 1 (red dot) | VCC | Red | 25XX (red stripe) | -| Pin 2 | Pin 2 | SO/MISO | Blue | DO (blue) | -| Pin 3 | Pin 3 | WP# | Brown | NC | -| Pin 4 | Pin 4 | GND | Black | GND (black) | -| Pin 5 | Pin 5 | SI/MOSI | Purple | DI (purple) | -| Pin 6 | Pin 6 | SCLK | Orange | CLK (orange) | -| Pin 7 | Pin 7 | HOLD# | White | NC | -| Pin 8 | Pin 8 | VCC | Red | VCC | +## Connection Examples -**Note**: Always verify pin 1 orientation by looking for the dot or notch on the chip. The red wire should connect to pin 1. +Test your programmer connection before attempting reads or writes. Run these from a Linux machine with `flashrom` installed. -## Connection Procedures +### Tigard -### Using Tigard ```bash -# Basic connection test sudo flashrom --programmer ft2232_spi:type=2232H,port=B,divisor=4 - -# With chip specification -sudo flashrom --programmer ft2232_spi:type=2232H,port=B,divisor=4 --chip "MX25L6405D" ``` -### Using CH347F +### CH347F + ```bash -# Basic connection test sudo flashrom --programmer ch347_spi - -# With chip specification and higher clock (example) -sudo flashrom --programmer ch347_spi --spispeed 60000 --chip "MX25L6405D" +# With higher clock (example): +sudo flashrom --programmer ch347_spi --spispeed 60000 ``` -### Using Raspberry Pi Pico (serprog) -```bash -# Basic connection test -sudo flashrom --programmer serprog:/dev/ttyACM0 +### CH341A Rev 1.6+ -# With chip specification and example clock -sudo flashrom --programmer serprog:/dev/ttyACM0 --spispeed 60000 --chip "MX25L6405D" --read backup.bin +```bash +sudo flashrom --programmer ch341a_spi ``` -- **Note:** Raspberry Pi Pico operates at **3.3V only**; do **not** use it for 1.8V chips. Ensure you have a Pico running a serprog-capable firmware and confirm its device node (e.g., `/dev/ttyACM0`). For 1.8V targets prefer Tigard or a CH347F module with VIO or use an external level shifter. +### [Raspberry Pi Pico](https://www.raspberrypi.com/products/raspberry-pi-pico/) ([serprog](https://www.flashrom.org/serprog)) -### Using CH341A rev 1.6+ ```bash -# Basic connection test -sudo flashrom --programmer ch341a_spi - -# With chip specification -sudo flashrom --programmer ch341a_spi --chip "MX25L6405D" +sudo flashrom --programmer serprog:/dev/ttyACM0 ``` +**Note:** 3.3V only. Verify the Pico is running [serprog](https://www.flashrom.org/serprog) firmware and the device node matches your system. -## Flashing Workflow - -**Tool notation:** This section uses `flash_tool` as a generic placeholder for flashing utilities (for example, `flashrom` or `flashprog`). Use the syntax: `flash_tool [read|write|verify] romname-for-platform`. Examples in this guide use `flashrom` — most commands are interchangeable with `flashprog`. +## Backup & Verify -**Protecting board-specific regions (GBE/IFD):** Many boards include small, board-specific regions (IFD / FMAP regions) that contain MAC addresses or other manufacturing data. **Always back up the full chip before the first flash** and inspect the dump (for example, `hexdump -C backup.bin | head -20`). +**This is the most important step.** Without verified backups, bricked hardware may be unrecoverable. -**Extremely important — keep multiple copies of your backups in a safe place.** If anything goes wrong or you need to restore stock firmware, these backups are required; if a backup is lost or corrupted, recovery may be impossible and we cannot help you. +```bash +# 1. Detect the chip +sudo [flasher] --programmer [programmer] -If your goal is to preserve a board's GBE/MAC value, consult the board's `boards/` build configuration and the community discussion in issue #120 for recommended workflows. +# 2. Read full chip backup +sudo [flasher] --programmer [programmer] --read backup1.bin --chip [chip] -For most users: back up the full chip and follow the per-board flashing instructions; advanced selective-region updates are an internal workflow—consult the `boards/` docs for details. +# 3. Inspect the dump (sanity check) +hexdump -C backup1.bin | head -20 +# 4. Verify the backup reads back correctly +sudo [flasher] --programmer [programmer] --verify backup1.bin --chip [chip] -### Chip Detection and Backup -```bash -# Test connection and detect chip -sudo flashrom --programmer [programmer] - -# Create backup and verify -sudo flashrom --programmer [programmer] --read backup.bin --chip "[chip_model]" -# Quick sanity check: inspect the start of the dump for obvious garbage -hexdump -C backup.bin | head -20 -sudo flashrom --programmer [programmer] --verify backup.bin --chip "[chip_model]" +# 5. Read a second backup to a different file (paranoia is good) +sudo [flasher] --programmer [programmer] --read backup2.bin --chip [chip] +sudo [flasher] --programmer [programmer] --verify backup2.bin --chip [chip] ``` -### Flash New Firmware +**Store backups in a safe, separate location.** If anything goes wrong or you need to restore stock firmware, these are your only recovery path. If they are lost or corrupted, recovery may be impossible and maintainers cannot help you. -**Before writing:** ensure you have a verified full-chip backup, confirmed chip VCC with a multimeter, and validated clip/contact stability. +> **Board-specific regions (GBE/IFD):** Some boards store MAC addresses or manufacturing data in chip regions. These are preserved by Heads during normal operation. For advanced selective-region workflows, consult your board's `boards/` build configuration and [issue #120](https://github.com/linuxboot/heads-wiki/issues/120). -**Step-by-step (safe & copyable):** +## Flashing New Firmware -1. Re-check the backup and inspect the start of the dump: +**Only proceed after verified backups.** ```bash -hexdump -C backup.bin | head -20 -sudo flashrom --programmer [programmer] --verify backup.bin --chip "[chip_model]" +sudo [flasher] --programmer [programmer] --chip [chip] --write firmware.rom --progress ``` -2. Write the new firmware (only after backups verified): +**Before writing, confirm:** +- Verified full-chip backup saved to a safe location +- Chip VCC confirmed with multimeter (or programmer voltage set correctly) +- Clip seated firmly with clean contacts +- Correct firmware file for your board (check path and filename) -```bash -sudo flashrom --programmer [programmer] --chip "[chip_model]" --write firmware.rom --progress -``` - -Notes: -- Always put `--programmer` before other `flashrom` options. -- Use `--progress` for long operations and monitor output. -- If verification fails, stop and troubleshoot (re-check clip, wiring, voltages, and your backup); do **not** retry writes until the issue is resolved. +If verification fails after writing: **do not retry**. Troubleshoot the connection first (clip seating, voltage, clock speed). See [Troubleshooting](#troubleshooting). ## Troubleshooting -### Common Issues and Solutions +### Chip Not Detected + +- Check clip connection and orientation (pin 1 alignment) +- **Do not guess voltage.** Measure chip VCC with a multimeter. +- Verify all power sources are disconnected (including CMOS battery). +- Increase clip contact pressure; clean chip pins with isopropyl alcohol. + +### Verification Fails -**Chip not detected**: -- Check clip connection and orientation -- **Do not** guess voltages. Measure the chip VCC with a multimeter to determine the correct operating voltage before attempting further reads. -- Verify all power sources are disconnected -- Check clip contact pressure +- Increase clip pressure or re-seat the clip. +- Clean chip pins and clip contacts with isopropyl alcohol. +- Reduce SPI clock speed: + - **CH347 / Pico:** `--spispeed 15000` (or lower) + - **Tigard:** increase divisor, e.g. `divisor=6` (10 MHz) or `divisor=8` (7.5 MHz) + - **CH341A:** no clock control; try a shorter/better USB cable or different USB port +- Check for oxidation on contacts; use flux if needed. -**Verification fails**: -- Increase clip pressure -- Clean chip pins with isopropyl alcohol -- Try lower clock speed (for Tigard: increase divisor) -- Check for oxidation on clip contacts +### Partial Writes / Intermittent Errors -**Partial writes**: -- Usually indicates poor connection -- Re-seat clip and try again -- Consider using probe-style adapter for better contact +- Usually a physical connection issue. Re-seat the clip. +- Consider a spring-loaded WSON probe or adapter jig for better contact (see below). +- Use a short, high-quality USB cable. ### WSON8 Package Tips -For WSON8 packages (surface mount without leads): -- Prefer a dedicated spring-loaded WSON8 probe or a purpose-built adapter jig with an alignment guide. These ensure correct pad alignment and consistent contact pressure for reliable reads/writes. -- Avoid using a standard SOIC/Pomona clip directly on WSON pads — clips can slip or fail to make reliable contact. If you must use a clip, use a PCB adapter or a probe designed for WSON packages. -- Use an assisted guider (spring or fixture) or 3D-printed jig to hold the probe steady during long operations to prevent intermittent connections. -- **Verify electrical contact before committing to a write:** read a full backup (`sudo flashrom --programmer [programmer] --read backup.bin`), inspect the start (`hexdump -C backup.bin | head -20`), and **always** confirm with `--verify` to ensure the dump is readable and stable (for example: `sudo flashrom --programmer [programmer] --verify backup.bin --chip "[chip_model]"`). -- Ensure you have good magnification and lighting when positioning the probe, and consider using flux or contact cleaners if multiple attempts fail. -![WSON8 Probe](https://github.com/user-attachments/assets/ebcd780b-c7db-466a-91ea-a0d9d546b3ec) +For WSON8 surface-mount packages (no leads): + +- Prefer a **spring-loaded WSON8 probe** or purpose-built adapter jig with alignment guide. These ensure correct pad alignment and consistent contact pressure. +- **Do not** use a standard SOIC/Pomona clip directly on WSON pads -- clips slip and fail to make reliable contact. If you must use a clip, use a PCB adapter designed for WSON. +- Use a spring-assisted guide or 3D-printed jig to hold the probe steady during long operations. +- Start by reading a backup and verifying it to confirm reliable contact before committing to a write. -> **Note:** For additional community photos and examples of spring-guided probes and jigs, see [issue #120](https://github.com/linuxboot/heads-wiki/issues/120). +![WSON8 Probe](https://github.com/user-attachments/assets/ebcd780b-c7db-466a-91ea-a0d9d546b3ec) -## Performance Optimization +See [issue #120](https://github.com/linuxboot/heads-wiki/issues/120) for community photos of spring-guided probes and jigs. -### SPI clock & performance (stability note) -- The observed read/write speeds are tied to the SPI clock used during the operation. If you increase the SPI clock (and your hardware remains stable), throughput increases roughly linearly; if you see instability or verification failures, reduce the SPI clock. -- Common parameters to change clock with `flashrom`: - - **CH347 / Pico (serprog)**: use `--spispeed ` (e.g. `--spispeed 60000` or `--spispeed 60M` for 60 MHz). The `spispeed` parameter accepts numeric kHz values or human‑readable strings (for example, `60M` or `937.5K`). CH347 modules normally provide discrete clock rates that scale by factors of two (for example **60M**, **30M**, **15M**, **7.5M**, **3.75M**, ...). Default CH347 clock in `flashrom` is commonly ~**15 MHz** but capable modules can run up to **60 MHz**; the Raspberry Pi Pico (serprog) accepts `--spispeed` similarly but is **3.3V only** and should only be used for 3.3V targets. - - **FT2232H** (used by Tigard-like FT2232 programmers): control clock via `divisor=` and the relationship is **clock = 60 MHz / n**. **Important:** `divisor` must be a **multiple of 2** (for example 2,4,6...). The default `divisor=2` yields the common default clock of **30 MHz**. For older/non‑H variants (FT2232C/FT2232D, which are rare) the base frequency is **12 MHz** (so `clock = 12 MHz / n` — e.g., `divisor=2` ⇒ 6 MHz); avoid non‑H variants if possible. In practice you usually do not need to calculate exact values — prefer defaults and only change `divisor` in multiples of 2 when troubleshooting performance/stability. - - **CH341A**: many CH341A modules do **not** support changing SPI clock via a `flashrom` parameter; treat CH341A as limited in clock control unless your specific module exposes a setting. -- If you experience verification failures: try **reducing** the clock (e.g., `--spispeed` or larger divisor) until reads/verifies become consistent. +### SPI Clock & Performance -**Example (community measurements):** -- **CH347F reading GD25LQ128E (16 MiB) at 60 MHz**: read ≈ **4 s**. Example write costs: erase ≈ **12 s** + write ≈ **110 s** + verify ≈ **4 s** = **126 s** total (community measurement — see issue #120). +SPI clock directly affects read/write speed. If you increase the clock, throughput scales roughly linearly -- until the connection becomes unstable. -**Links & sources:** -- [CH347 datasheet](https://www.wch-ic.com/downloads/CH347DS1_PDF.html) 🔗 -- [CH347 review & schematic (OneTransistor)](https://www.onetransistor.eu/2024/09/ch347t-programmer-schematic.html) 🔗 -- [FT2232H datasheet](https://ftdichip.com/wp-content/uploads/2020/08/DS_FT2232H.pdf) 🔗 -- [Flashrom documentation](https://www.flashrom.org/Flashrom) 🔗 -- [Community timings/discussion: issue #120](https://github.com/linuxboot/heads-wiki/issues/120) 🔗 +**Clock control by programmer:** -### Tigard Speed Optimization -- Use `divisor=4` for reliable operation -- Use `divisor=2` for maximum speed (may be less stable) -- Enable progress indicator: `--progress` +| Programmer | Parameter | Notes | +|------------|-----------|-------| +| CH347 | `--spispeed ` (e.g. `--spispeed 60000`) | Default ~15 MHz, max 60 MHz. Use powers-of-two steps: 60M, 30M, 15M, 7.5M... | +| Pico (serprog) | `--spispeed ` | 3.3V only | +| Tigard (FT2232H) | `divisor=` | Clock = 60 MHz / n. `n` must be even (2, 4, 6...). Default `divisor=2` = 30 MHz. | +| CH341A | N/A | No adjustable SPI clock | -## Recommended Kits +**If verification fails, reduce the clock** (lower `--spispeed` or larger `divisor`) until reads/verifies become consistent. -### Complete Kits (Assembled and Ready) -See the **CH341A** subsection for CH341-specific kits and safety checks; for Tigard-based kits see the Tigard project's pages linked in the Tigard subsection. +**Example (community measurement):** CH347F reading GD25LQ128E (16MB) at 60 MHz: read ~4s, erase ~12s, write ~110s, verify ~4s = ~126s total. -### Individual Components -- **Tigard**: [Crowd Supply](https://www.crowdsupply.com/securinghw/tigard) -- **WSON8 probe**: [Amazon](https://www.amazon.ca/dp/B0DJ8XTCKD) +**References:** [CH347 datasheet](https://www.wch-ic.com/downloads/CH347DS1_PDF.html) | [FT2232H datasheet](https://ftdichip.com/wp-content/uploads/2020/08/DS_FT2232H.pdf) | [Flashrom docs](https://www.flashrom.org/) | [Community benchmarks: issue #120](https://github.com/linuxboot/heads-wiki/issues/120) ## Summary -For most users, **Tigard is the recommended choice** due to its: -- Fast operation (saves time during development) -- Multiple voltage options (safe for all chips) -- Additional debugging capabilities -- Excellent reliability record +**Tigard** is the recommended choice: fast, multi-voltage, excellent reliability, debugging features. Worth the cost for anyone flashing more than once. + +**CH347F** is the best budget option when you need speed and adjustable VIO. Verify the module exposes VIO before buying. -**Budget & fast option:** **CH347F** is a good budget choice when you need higher speed and adjustable VIO; verify the specific module exposes VIO and how to configure it. +**CH341A rev 1.6+** is acceptable for occasional use with a physical voltage selector. Expect long read/write times and basic SPI-only operation. **Never use old CH341 modules without voltage selection** -- they can destroy your hardware. -**Budget & basic option:** **CH341A rev 1.6+** is acceptable for occasional flashing but: -- Verify it has a physical voltage selector or regulator -- Expect longer read/write times -- Limited to basic SPI operations +**[Raspberry Pi Pico](https://www.raspberrypi.com/products/raspberry-pi-pico/)** is a capable DIY option for 3.3V-only workflows, requiring more setup. -**DIY option:** **Raspberry Pi Pico** is a capable DIY option for 3.3V-only workflows (requires more setup). +## Component Sources -**Never use old CH341A programmers** without voltage selection — they can damage your hardware. +- **Tigard:** [Crowd Supply](https://www.crowdsupply.com/securinghw/tigard) +- **CH341A kits:** [3mdeb](https://shop.3mdeb.com/shop/modules/ch341a-flash-bios-usb-programmer-kit-soic8-sop8/) | [Novacustom](https://novacustom.com/product/modded-ch341a-bios-firmware-programmer-3v/) +- **WSON8 probe:** [Amazon](https://www.amazon.ca/dp/B0DJ8XTCKD) diff --git a/Installing-and-Configuring/Flashing-Guides/T420-maximized.md b/Installing-and-Configuring/Flashing-Guides/T420-maximized.md index 27b42d3..36ff29c 100644 --- a/Installing-and-Configuring/Flashing-Guides/T420-maximized.md +++ b/Installing-and-Configuring/Flashing-Guides/T420-maximized.md @@ -9,21 +9,84 @@ grand_parent: Installing and configuring Lenovo T420 (Maximized) === +
+ + Table of contents + + {: .text-delta } +1. TOC +{:toc} +
-## ⚠️ Safety First +## ⚠️ EOL: No microcode updates +{: .warning } +This board's CPU generation has reached End of Servicing Updates. +See [per-board EOL/ESU status](https://github.com/linuxboot/heads/blob/master/doc/BOARDS_AND_TESTERS.md#per-board-eolesu-status) +for ESU dates and [Heads threat model]({{ site.baseurl }}/Heads-threat-model/#binary-blobs-microcode-updates-and-transient-execution-vulnerabilities) +for security implications. + +## ✅ PROTECTED: TPM GPIO Reset +{: .warning } + +Pre-Skylake platform — dedicated PLTRST# pin, not GPIO-shared. +See [Per-Board Protection Status]({{ site.baseurl }}/Heads-threat-model/#per-board-protection-status), +[TPM GPIO Reset Vulnerability](https://github.com/linuxboot/heads/blob/master/doc/TPM_GPIO_Reset_Vulnerability.md). + + + +## ⚡ Safety First **Before starting, please read our [SPI Programmer Best Practices guide]({{ site.baseurl }}/SPI-Programmer-Best-Practices/) for essential safety information and programmer recommendations.** [T420 Hardware Maintenance Manual](https://download.lenovo.com/pccbbs/mobiles_pdf/t420_and_t420i_ug_en.pdf) -The thinkpad T420 has only one SPI flash chip that holds the BIOS, ME, etc. It is located under the palm rest. Similarly to the T430, to access this chip complete disassembly is required. It is a straightforward process and takes approximately 30 minutes. For this follow the T430/x230 guide. +## Disassembly + +→ **[Libreboot T420 external flashing guide](https://libreboot.org/docs/install/t420_external.html)** (detailed disassembly photos) +→ **[Lenovo T420 Hardware Maintenance Manual](https://download.lenovo.com/pccbbs/mobiles_pdf/t420_and_t420i_ug_en.pdf)** + +The T420 has a **single 8 MB SPI flash chip** (Winbond W25Q64CV) that holds the BIOS, ME firmware, and flash descriptor. Unlike the T430 and X230 (which use two separate chips), no ROM splitting is required. + +### Tools required + +- Flat-nose pliers (or sleeve tool for VGA screws) +- Phillips screwdriver (various sizes) +- Small crowbar or spudger (for prying keyboard and bezel) +- CPU thermal grease (for reassembly) +- Spare screws (some may strip during disassembly) -**Critical**: Remove all batteries (including CMOS) AND disconnect the AC adapter before starting. +**Critical**: Remove all batteries (including the CMOS RTC battery) AND disconnect the AC adapter before starting. -[Here](https://www.coreboot.org/Board:lenovo/t420) is the location of the chip. At some models the location of the dot where the red wire from programmer should go may be misleading. The dot you need is just black. +### Disassembly steps + +Full motherboard extraction is required — the T420 is more involved than the T430 because the main board must be separated from the magnesium frame. Budget approximately 30 minutes. + +1. **Bottom covers** — Remove the main battery, ultrabay device, and all screws on the black bottom cover. +2. **Keyboard** — Use a small crowbar to push the keyboard gently toward the screen. Lift it and detach the ribbon cable. +3. **Front cover (palm rest)** — Pry up around the sides with a spudger, lift the palm rest off, and disconnect the touchscreen/pointing-stick ribbon cable. +4. **Internal components**: + - Speaker (red screws) + - Modem/telephone jack and WWAN card (pink screws) + - Screen assembly (green screws) — note cable routing for reassembly +5. **Fan assembly** — Disconnect the USB port connections (blue) and remove the fan screws (red). +6. **Bottom cover** — Flip the machine over and remove all visible screws securing the magnesium frame. +7. **VGA port** — The VGA connector screws are unusually tight; loosen with flat-nose pliers or a sleeve tool. +8. **Main board** — Lift the main board carefully off the magnesium frame, checking that no cables remain attached. + +The SPI flash chip is on the front of the board once the main board is free: + +[Here](https://doc.coreboot.org/mainboard/lenovo/t420.html) is the location of the chip. On some models the orientation dot marking pin 1 may be misleading — the correct dot is just black. ![T420 SPI flash chip]({{ site.baseurl }}/images/T420_SPI_chip.jpg) **Note**: See the [SPI Programmer Best Practices]({{ site.baseurl }}/SPI-Programmer-Best-Practices/) for programmer recommendations (Tigard recommended; CH347F preferred budget option; CH341A rev1.6+ acceptable with a physical selector). +## Preparing the ROM + +First [download]({{ site.baseurl }}/Downloading) or build the maximized board ROM for the T420 and verify its hash. Since the T420 uses a single 8 MB flash chip, no ROM splitting is needed — the full `heads-t420-maximized.rom` is written directly to the single chip. + +## Flashing + +Use `[flasher]` (flashrom or flashprog -- see [Tool Interchangeability]({{ site.baseurl }}/SPI-Programmer-Best-Practices/#tool-interchangeability)) to create a backup, verify, then write the Heads ROM. See the Libreboot guide linked above for chip location and `[flasher]` command examples. + You should then follow through with [configuring keys]({{ site.baseurl }}/Configuring-Keys/). diff --git a/Installing-and-Configuring/Flashing-Guides/T430-maximized.md b/Installing-and-Configuring/Flashing-Guides/T430-maximized.md index 33800b6..4e1d06a 100644 --- a/Installing-and-Configuring/Flashing-Guides/T430-maximized.md +++ b/Installing-and-Configuring/Flashing-Guides/T430-maximized.md @@ -2,23 +2,49 @@ layout: default title: Lenovo T430 Maximized permalink: /T430-maximized-flashing/ -nav_order: 3 +nav_order: 5 parent: Step 2 - Flashing Guides grand_parent: Installing and configuring --- Lenovo T430 (Maximized) === +
+ + Table of contents + + {: .text-delta } +1. TOC +{:toc} +
-## ⚠️ Safety First +## ⚠️ EOL: No microcode updates +{: .warning } +This board's CPU generation has reached End of Servicing Updates. +See [per-board EOL/ESU status](https://github.com/linuxboot/heads/blob/master/doc/BOARDS_AND_TESTERS.md#per-board-eolesu-status) +for ESU dates and [Heads threat model]({{ site.baseurl }}/Heads-threat-model/#binary-blobs-microcode-updates-and-transient-execution-vulnerabilities) +for security implications. + +## ✅ PROTECTED: TPM GPIO Reset +{: .warning } + +Pre-Skylake platform — dedicated PLTRST# pin, not GPIO-shared. +See [Per-Board Protection Status]({{ site.baseurl }}/Heads-threat-model/#per-board-protection-status), +[TPM GPIO Reset Vulnerability](https://github.com/linuxboot/heads/blob/master/doc/TPM_GPIO_Reset_Vulnerability.md). + + + +## ⚡ Safety First **Before starting, please read our [SPI Programmer Best Practices guide]({{ site.baseurl }}/SPI-Programmer-Best-Practices/) for essential safety information and programmer recommendations.** [T430 Hardware Maintenance Manual](https://download.lenovo.com/ibmdl/pub/pc/pccbbs/mobiles_pdf/t430_t430i_hmm_en_0b48304_04.pdf) -Similarly to the x230, the thinkpad T430 has two SPI flash chips that hold the BIOS, ME, etc. They are located under the palm rest. To access these chips, complete disassembly is required. It is a straightforward process and takes approximately 30 minutes. For this you will need: some screwdrivers, thermal paste (since the CPU cooler needs to be removed too), a recommended SPI programmer (see our [Best Practices guide]({{ site.baseurl }}/SPI-Programmer-Best-Practices/)), and another laptop/PC with Ubuntu installed. Other linux based OS should be fine too. +→ **[Coreboot T430 documentation](https://doc.coreboot.org/mainboard/lenovo/t430.html)** (chip layout, flashing instructions) -**Critical**: Remove all batteries (including CMOS) AND disconnect the AC adapter before starting. +## Disassembly + +First remove the battery and the cable powering your device. ![Keyboard tilted up]({{ site.baseurl }}/images/t430/1_1_back_view_removed_battery.jpg) @@ -59,25 +85,23 @@ Left chip corresponds to the "bottom" flash chip (8192 kb) and right corresponds ![SPI flash chips]({{ site.baseurl }}/images/t430/10_spi_flash_chips.jpg) -First [download]({{ site.baseurl }}/Downloading) or build (please see [general building]({{ site.baseurl }}/{{ site.baseurl }}/x230-maximized-building/) / [building x230]({{ site.baseurl }}/x230-maximized-building/)) the maximized board roms (top and bottom) for this board and verify their hashes. - -**Note:** If you need to reflash or customize the EC firmware while still on proprietary platform firmware, refer to the **EC firmware & customizations** section in the [Prerequisites]({{ site.baseurl }}/Prerequisites) for guidance on performing EC updates and customizations from vendor firmware prior to the initial Heads flash. +First [download]({{ site.baseurl }}/Downloading) or build (please see [general building]({{ site.baseurl }}/x230-maximized-building/) / [building x230]({{ site.baseurl }}/x230-maximized-building/)) the maximized board roms (top and bottom) for this board and verify their hashes. Try to read the name on the top SPI flash chip. I was unable to do that. The dots on the chip help to identify the correct clip orientation. ![SPI flash chips closed view]({{ site.baseurl }}/images/t430/11_spi_chips_closed_view.jpg) - Then, connect the clip and SPI programmer to the "top" (4096 kb) SPI flash chip. In my set up, the red wire should be where the dot is. - -**Note**: See the [SPI Programmer Best Practices]({{ site.baseurl }}/SPI-Programmer-Best-Practices/) for programmer recommendations (Tigard recommended; CH347F preferred budget option; CH341A rev1.6+ acceptable with a physical selector). The commands below use `[programmer]` as a placeholder; see the SPI Programmer Best Practices guide for example commands for specific programmers. + Then, connect the clip and ch341a programmer to the "top" (4096 kb) SPI flash chip. In my set up, the red wire should be where the dot is. ![Flashing 4 mb chip]({{ site.baseurl }}/images/t430/12_flash_4mb_spi_chip.jpg) - Use flashrom to check the chip that you are connected to: +## Flashing + +Use `[flasher]` of your choice (flashrom or flashprog -- see [Tool Interchangeability]({{ site.baseurl }}/SPI-Programmer-Best-Practices/#tool-interchangeability)) with the programmer you selected ([programmer] -- see [Programmer Selection]({{ site.baseurl }}/SPI-Programmer-Best-Practices/#programmer-selection)): ```shell -sudo flashrom --programmer [programmer] +sudo [flasher] --programmer [programmer] ``` @@ -85,23 +109,21 @@ sudo flashrom --programmer [programmer] ![output top 4 mb chip]({{ site.baseurl }}/images/t430/13_ubuntu_output_4mb.jpg) -Find the chip and create a backup and verify it (For me the SPI flash chip is `YYY`): +Find the chip and read from it twice (For me the SPI flash chip is `YYY`): ```shell -sudo flashrom --programmer [programmer] --read ~/top.bin --chip YYY -# Quick sanity check: inspect the start of the dump for obvious garbage -hexdump -C ~/top.bin | head -20 -sudo flashrom --programmer [programmer] --verify ~/top.bin --chip YYY +sudo [flasher] --read ~/top.bin --programmer [programmer] --chip YYY && \ + sudo [flasher] --verify ~/top.bin --programmer [programmer] --chip YYY ``` If the files differ then try reconnecting your programmer to the SPI flash chip - and make sure your flashrom software is up to date. + and make sure your flashrom/flashprog software is up to date. If they are the same then write `t430-maximized-top.rom` to the SPI flash chip: ```shell -sudo flashrom --programmer [programmer] --chip YYY --write ~/heads/build/x86/t430-maximized/t430-maximized-top.rom +sudo [flasher] --programmer [programmer] --chip YYY --write ~/heads/build/x86/t430-maximized/t430-maximized-top.rom ``` While everything goes well you should see the blue LED on the programmer. @@ -115,37 +137,32 @@ sudo flashrom --programmer [programmer] --chip YYY --write ~/heads/build/x86/t43 Try to read the name on the bottom SPI flash chip. Then, connect the clip and - SPI programmer to the bottom SPI flash chip. + ch341a programmer to the bottom SPI flash chip. ![flashing bottom 8 mb chip]({{ site.baseurl }}/images/t430/16_flash_8mb_chip.jpg) - Use flashrom to check the chip that you are connected to: +Use `[flasher]` of your choice (flashrom or flashprog -- see [Tool Interchangeability]({{ site.baseurl }}/SPI-Programmer-Best-Practices/#tool-interchangeability)) with the programmer you selected ([programmer] -- see [Programmer Selection]({{ site.baseurl }}/SPI-Programmer-Best-Practices/#programmer-selection)): ```shell -sudo flashrom --programmer [programmer] +sudo [flasher] --programmer [programmer] ``` Here is my output. ![output bottom 8 mb chip]({{ site.baseurl }}/images/t430/17_ubuntu_output_8mb.jpg) -Find the chip and create a backup and verify it (For me the SPI flash chip is `ZZZ`): +Find the chip and read from the chip twice (For me the SPI flash chip is `ZZZ`): ```shell -sudo flashrom --programmer [programmer] --read ~/bottom.bin --chip ZZZ -# Quick sanity check: inspect the start of the dump for obvious garbage -hexdump -C ~/bottom.bin | head -20 -sudo flashrom --programmer [programmer] --verify ~/bottom.bin --chip ZZZ +sudo [flasher] --read ~/bottom.bin --programmer [programmer] --chip ZZZ && \ + sudo [flasher] --verify ~/bottom.bin --programmer [programmer] --chip ZZZ ``` The 8M bottom chip contains the ME firmware. It is neutralized in maximized version. You can flash it specifying the same chip you found under ZZZ: ```shell -sudo flashrom --programmer [programmer] --chip ZZZ --write ~/heads/build/x86/t430-maximized/t430-maximized-bottom.rom +sudo [flasher] --programmer [programmer] --chip ZZZ --write ~/heads/build/x86/t430-maximized/t430-maximized-bottom.rom ``` -**Note about GBE:** The T430 contains a GBE region (board MACs) inside the Intel Firmware Descriptor (IFD). **Always back up the full chip before the initial flash** and inspect the dump (for example, `hexdump -C ~/bottom-backup.bin | head -20`). - -If you need to preserve a board's MAC/GBE, the reliable approach is to create a custom GBE during the Heads build (see the `boards/` configuration in linuxboot/heads). For details on preserving board-specific regions, consult the SPI Programmer Best Practices guide and the board's build documentation, and refer to issue #120 for community discussion. If all goes well, you should see the keyboard LED flash, and within a second Heads will boot in its GUI. Two reboots are sometimes needed after flash. Force power off by holding the power button for 10 seconds. Since the memory training data was wiped by the content of the full flashed ROM, this is normal. diff --git a/Installing-and-Configuring/Flashing-Guides/T440p-maximized.md b/Installing-and-Configuring/Flashing-Guides/T440p-maximized.md new file mode 100644 index 0000000..c71b7fa --- /dev/null +++ b/Installing-and-Configuring/Flashing-Guides/T440p-maximized.md @@ -0,0 +1,80 @@ +--- +layout: default +title: Lenovo T440p Maximized +permalink: /T440p-maximized-flashing/ +nav_order: 6 +parent: Step 2 - Flashing Guides +grand_parent: Installing and configuring +--- + +Lenovo T440p (Maximized) +=== + +
+ + Table of contents + + {: .text-delta } +1. TOC +{:toc} +
+ +## ⚠️ EOL: No microcode updates +{: .warning } +This board's CPU generation has reached End of Servicing Updates. +See [per-board EOL/ESU status](https://github.com/linuxboot/heads/blob/master/doc/BOARDS_AND_TESTERS.md#per-board-eolesu-status) +for ESU dates and [Heads threat model]({{ site.baseurl }}/Heads-threat-model/#binary-blobs-microcode-updates-and-transient-execution-vulnerabilities) +for security implications. + +## ✅ PROTECTED: TPM GPIO Reset +{: .warning } +Pre-Skylake — dedicated PLTRST# pin. +See [Per-Board Protection Status]({{ site.baseurl }}/Heads-threat-model/#per-board-protection-status), +[TPM GPIO Reset Vulnerability](https://github.com/linuxboot/heads/blob/master/doc/TPM_GPIO_Reset_Vulnerability.md). + +## ⚡ Safety First +**Before starting, please read our [SPI Programmer Best Practices guide]({{ site.baseurl }}/SPI-Programmer-Best-Practices/) for essential safety information and programmer recommendations.** + +## Disassembly + +The T440p has **two SPI flash chips** — an 8 MB chip (SPI1) and a 4 MB chip (SPI2). The Heads ROM must be split before flashing: + +```shell +dd if=heads-t440p-maximized.rom of=spi1_8mb.rom bs=1M count=8 +dd if=heads-t440p-maximized.rom of=spi2_4mb.rom bs=1M skip=8 +``` + +Flash the 8 MB chip (SPI1) with `spi1_8mb.rom` and the 4 MB top chip (SPI2) with `spi2_4mb.rom`. + +### Step-by-step disassembly + +1. Remove the back cover screws and the main battery. +2. Slide off the back cover. +3. Unplug the CMOS battery, the fan cable, and the black LED cable. +4. Remove all visible screws holding the bottom assembly (the ultrabay screw loosens but does not come out). +5. Pry up around the sides of the bottom assembly to release the clips, then lift it open like a clamshell toward the front — take care not to snap any wires. +6. The two flash chips are now visible near the RAM. The chip labeled **SPI1** is the 8 MB chip; the chip labeled **SPI2** (mounted above it) is the 4 MB chip. + +For reference photos and detailed mechanical guidance, consult: +- **[Libreboot T440p external flashing guide](https://libreboot.org/docs/install/t440p_external.html)** — photo disassembly and ROM-splitting instructions +- **[Coreboot T440p documentation](https://doc.coreboot.org/mainboard/lenovo/t440p.html)** — chip layout and flashing commands +- The Lenovo hardware maintenance manual is available from [Lenovo support](https://pcsupport.lenovo.com/us/en/products/laptops-and-netbooks/thinkpad-t-series-laptops/thinkpad-t440p) (search for "Hardware Maintenance Manual") + +## Flashing + +Connect your SPI programmer to the chip(s) being programmed, respecting pin 1 on each chip. Write each half of the split ROM to the corresponding chip: + +Use `[flasher]` of your choice (flashrom or flashprog -- see [Tool Interchangeability]({{ site.baseurl }}/SPI-Programmer-Best-Practices/#tool-interchangeability)) with the programmer you selected ([programmer] -- see [Programmer Selection]({{ site.baseurl }}/SPI-Programmer-Best-Practices/#programmer-selection)): + +```shell +[flasher] --programmer [programmer] --chip "W25Q64FV" --write spi1_8mb.rom +[flasher] --programmer [programmer] --chip "W25Q32FV" --write spi2_4mb.rom +``` + +Replace `[programmer]` with your hardware (e.g. `linux_spi:dev=/dev/spidev0.0`, `ft2232_spi:type=2232H`, or `ch341a_spi`). + +### Haswell-specific notes + +- **[thinkpad_acpi](https://www.kernel.org/doc/html/latest/admin-guide/laptops/thinkpad-acpi.html)**: After the first boot with Heads, the `thinkpad_acpi` kernel module may need the `fan_control=1` parameter to enable manual fan control. Add `thinkpad_acpi.fan_control=1` to the kernel command line or pass it as a module parameter. +- **[MRC](https://doc.coreboot.org/soc/intel/fsp.html) (Memory Reference Code)**: The T440p uses Haswell MRC training data stored in SPI flash. If the flash layout is corrupted or you are flashing a completely blank board, the machine may not boot until MRC training runs. Heads does not include a built-in MRC cache; the first boot after flashing may take 30–60 seconds as the platform retrains memory. Subsequent boots will reuse cached parameters. +- **GPIO PLTRST#**: As noted above, the T440p has a dedicated PLTRST# pin for TPM GPIO reset, making it one of the better-protected pre-Skylake boards in the Heads threat model. diff --git a/Installing-and-Configuring/Flashing-Guides/T480-maximized.md b/Installing-and-Configuring/Flashing-Guides/T480-maximized.md index 7f8ea3e..b9d7efd 100644 --- a/Installing-and-Configuring/Flashing-Guides/T480-maximized.md +++ b/Installing-and-Configuring/Flashing-Guides/T480-maximized.md @@ -2,7 +2,7 @@ layout: default title: Lenovo T480 Maximized permalink: /T480-maximized-flashing/ -nav_order: 5 +nav_order: 7 parent: Step 2 - Flashing Guides grand_parent: Installing and configuring --- @@ -10,7 +10,30 @@ grand_parent: Installing and configuring Lenovo T480 (Maximized) === -## ⚠️ Safety First +
+ + Table of contents + + {: .text-delta } +1. TOC +{:toc} +
+ +## ⚠️ EOL: No microcode updates +{: .warning } +This board's CPU generation has reached End of Servicing Updates. +See [per-board EOL/ESU status](https://github.com/linuxboot/heads/blob/master/doc/BOARDS_AND_TESTERS.md#per-board-eolesu-status) +for ESU dates and [Heads threat model]({{ site.baseurl }}/Heads-threat-model/#binary-blobs-microcode-updates-and-transient-execution-vulnerabilities) +for security implications. + +## 🛡️ VULNERABLE: TPM GPIO Reset +{: .critical } + +TPMTOTP/HOTP bypassable. Disk encryption with passphrase unaffected. +See [Per-Board Protection Status]({{ site.baseurl }}/Heads-threat-model/#per-board-protection-status), +[TPM GPIO Reset Vulnerability](https://github.com/linuxboot/heads/blob/master/doc/TPM_GPIO_Reset_Vulnerability.md). + +## ⚡ Safety First **Before starting, please read our [SPI Programmer Best Practices guide]({{ site.baseurl }}/SPI-Programmer-Best-Practices/) for essential safety information and programmer recommendations.** @@ -36,7 +59,7 @@ Some ThinkPad T480 units on the used market are affected by an Intel bug in the Please note that as of March 2025, Thunderbolt data transfer is not supported upstream by [coreboot](https://review.coreboot.org/c/coreboot/+/83274). However, video output through Thunderbolt and charging still work. This means only the USB-C charging port can be used for data transfer. -## Flashing Heads +## Disassembly First, remove the batteries and disconnect the power cable from your device. Removing the screws will allow you to remove the back panel. A guitar pick or an old credit card can be helpful for detaching the panel. @@ -58,13 +81,15 @@ Try to read the name of the SPI flash chip. The dot on the chip helps to identif ![SPI BIOS flash chip closed view]({{ site.baseurl }}/images/T480/4_bios_chip_orientation.jpg) - First, connect the clip of your SPI programmer to the chip (see the [SPI Programmer Best Practices guide]({{ site.baseurl }}/SPI-Programmer-Best-Practices/) for recommended hardware and example commands). Next, connect the programmer to the USB port of your other Linux-based computer with flashrom installed. In my setup, the red wire should be where the dot is (the dot indicates pin 1). Here, please also see the flashing guide for the T430. +## Flashing + +First, connect the clip of your SPI programmer to the chip (see the [SPI Programmer Best Practices guide]({{ site.baseurl }}/SPI-Programmer-Best-Practices/) for recommended hardware and example commands). Next, connect the programmer to the USB port of your other Linux-based computer with flashrom/flashprog installed. In my setup, the red wire should be where the dot is (the dot indicates pin 1). Here, please also see the flashing guide for the T430. **Note:** For initial reflashing steps that involve customizing the EC while still on proprietary firmware (for example to preserve or alter EC features), see the X230 reflashing notes and building guidance for detailed instructions and cautions. - Use flashrom to check the chip you are connected to: +Use `[flasher]` of your choice (flashrom or flashprog -- see [Tool Interchangeability]({{ site.baseurl }}/SPI-Programmer-Best-Practices/#tool-interchangeability)) with the programmer you selected ([programmer] -- see [Programmer Selection]({{ site.baseurl }}/SPI-Programmer-Best-Practices/#programmer-selection)): ```shell -sudo flashrom --programmer [programmer] +sudo [flasher] --programmer [programmer] ``` Here is my output. @@ -74,17 +99,17 @@ Here is my output. Create a backup and verify it (where the name of the flash chip is `YYY`): ```shell -sudo flashrom --programmer [programmer] --read ~/t480_original_bios.bin --chip YYY +sudo [flasher] --programmer [programmer] --read ~/t480_original_bios.bin --chip YYY # Quick sanity check: inspect the start of the dump for obvious garbage hexdump -C ~/t480_original_bios.bin | head -20 -sudo flashrom --programmer [programmer] --verify ~/t480_original_bios.bin --chip YYY +sudo [flasher] --programmer [programmer] --verify ~/t480_original_bios.bin --chip YYY ``` First output can be seen here. ![1-st read]({{ site.baseurl }}/images/T480/6_lenovo_bios.jpg) ```shell -sudo flashrom --programmer [programmer] --read ~/t480_original_bios_1.bin --chip YYY +sudo [flasher] --programmer [programmer] --read ~/t480_original_bios_1.bin --chip YYY ``` Second output can be seen here. ![2-nd read]({{ site.baseurl }}/images/T480/7_lenovo_bios_1.jpg) @@ -92,11 +117,11 @@ Second output can be seen here. Make sure that the dump matches the chip content. If this is the case, the output of the following command will state `Verifying flash... VERIFIED` ```shell -sudo flashrom --programmer [programmer] --verify ~/t480_original_bios.bin --chip YYY +sudo [flasher] --programmer [programmer] --verify ~/t480_original_bios.bin --chip YYY ``` Make sure that files do not differ. -# If the dumps look consistent, proceed (visual comparison shown above). +**If the dumps look consistent, proceed (visual comparison shown above).** Alternative comparison is bit-by-bit. If the files are the same, there should be no output of this command. Otherwise, you will see a bit-by-bit difference between the files. @@ -111,7 +136,7 @@ If the files differ or the chip content does not match the dump, try reconnectin If they are the same, then write `T480-hotp-maximized.rom` to the SPI flash chip: ```shell -sudo flashrom --programmer [programmer] --chip YYY --write ~/heads/build/x86/T480-hotp-maximized/T480-hotp-maximized.rom +sudo [flasher] --programmer [programmer] --chip YYY --write ~/heads/build/x86/T480-hotp-maximized/T480-hotp-maximized.rom ``` **Note about GBE:** The T480 includes a GBE region (board MACs) inside the Intel Firmware Descriptor (IFD). **Always back up the full chip before the initial flash** and inspect the dump (for example, `hexdump -C ~/bios-backup.bin | head -20`). @@ -131,15 +156,15 @@ You should then follow through with [configuring keys]({{ site.baseurl }}/Config Important, ensure that power supply and all batteries, including the CMOS battery, are disconnected. After connecting the clip to the Thunderbolt chip as shown in the figure above read from the chip, making sure the connection is stable. The procedure is similar to the flashing Heads on the SPI chip. Therefore, comments are skipped. ```shell -sudo flashrom --programmer [programmer] --read ~/t480_original_tb.bin --chip YYY +sudo [flasher] --programmer [programmer] --read ~/t480_original_tb.bin --chip YYY # Quick sanity check: inspect the start of the dump for obvious garbage hexdump -C ~/t480_original_tb.bin | head -20 -sudo flashrom --programmer [programmer] --read ~/t480_original_tb_1.bin --chip YYY +sudo [flasher] --programmer [programmer] --read ~/t480_original_tb_1.bin --chip YYY # Quick sanity check: inspect the start of the dump for obvious garbage hexdump -C ~/t480_original_tb_1.bin | head -20 -sudo flashrom --programmer [programmer] --verify ~/t480_original_tb.bin --chip YYY +sudo [flasher] --programmer [programmer] --verify ~/t480_original_tb.bin --chip YYY # Bit-by-bit comparison: diff <(hexdump -C t480_original_tb.bin) <(hexdump -C t480_original_tb_1.bin) @@ -147,6 +172,6 @@ diff <(hexdump -C t480_original_tb.bin) <(hexdump -C t480_original_tb_1.bin) Flash the padded Thunderbolt firmware. The firmware file tb.bin is located in the blobs folder after you build the Heads locally, or in the CircleCI artifacts. ```shell -sudo flashrom --programmer [programmer] --chip YYY --write ~/tb.bin +sudo [flasher] --programmer [programmer] --chip YYY --write ~/tb.bin ``` Done. diff --git a/Installing-and-Configuring/Flashing-Guides/T480s-maximized.md b/Installing-and-Configuring/Flashing-Guides/T480s-maximized.md index 580c96a..256e3dd 100644 --- a/Installing-and-Configuring/Flashing-Guides/T480s-maximized.md +++ b/Installing-and-Configuring/Flashing-Guides/T480s-maximized.md @@ -2,13 +2,41 @@ layout: default title: Lenovo T480s Maximized permalink: /T480s-maximized-flashing/ -nav_order: 1 +nav_order: 8 parent: Step 2 - Flashing Guides grand_parent: Installing and configuring --- Lenovo T480s (Maximized) === +
+ + Table of contents + + {: .text-delta } +1. TOC +{:toc} +
+ +## ⚠️ EOL: No microcode updates +{: .warning } +This board's CPU generation has reached End of Servicing Updates. +See [per-board EOL/ESU status](https://github.com/linuxboot/heads/blob/master/doc/BOARDS_AND_TESTERS.md#per-board-eolesu-status) +for ESU dates and [Heads threat model]({{ site.baseurl }}/Heads-threat-model/#binary-blobs-microcode-updates-and-transient-execution-vulnerabilities) +for security implications. + +## 🛡️ VULNERABLE: TPM GPIO Reset +{: .critical } + +TPMTOTP/HOTP bypassable. Disk encryption with passphrase unaffected. +See [Per-Board Protection Status]({{ site.baseurl }}/Heads-threat-model/#per-board-protection-status), +[TPM GPIO Reset Vulnerability](https://github.com/linuxboot/heads/blob/master/doc/TPM_GPIO_Reset_Vulnerability.md). + + + +## ⚡ Safety First + +**Before starting, please read our [SPI Programmer Best Practices guide]({{ site.baseurl }}/SPI-Programmer-Best-Practices/) for essential safety information and programmer recommendations.** [T480s Hardware Maintenance Manual](https://download.lenovo.com/pccbbs/mobiles_pdf/t480s-hmm_en.pdf) @@ -26,9 +54,6 @@ There is still debate over which programmer and software should be used (flashpr Some ThinkPad T480s units on the used market, like the T480, are affected by an Intel bug in the Thunderbolt firmware. In short, the flash chip becomes full, causing Thunderbolt fast charging to stop working, though slow charging still functions. This issue can also affect the USB-C port. For convenience, Heads provides a fixed and padded Thunderbolt firmware that resolves the "charging problem" if your laptop is affected. Board testers did not encounter this issue, and it is unlikely to occur if your laptop was in use for more than 12 months before flashing. If you do experience the "charging bug," it is possible to fix it with external flashing. Also, the update is possible prior flashing heads using [fwupd from a Linux distribution](https://www.reddit.com/r/thinkpad/comments/12tf6xv/psa_t480_thunderbolt_controller_v23_is_now_on/) -Please note that as of March 2025, Thunderbolt data transfer is not supported upstream by [coreboot](https://review.coreboot.org/c/coreboot/+/83274). However, video output through Thunderbolt and charging still work. This means only the USB-C charging port can be used for data transfer. - -## (Optional) Updating EC Firmware Before flashing heads, it is advisable to update the EC Firmware on the laptop. Some old EC firmware may be vulnerable to some serious CVEs. See [Heads-threat-model]({{ site.baseurl }}/Heads-threat-model/#binary-blobs-microcode-updates-and-transient-execution-vulnerabilities) for additional information. @@ -59,7 +84,7 @@ sudo dd if=t480s_bootable_update_utility.img of=/dev/sdX status=progress Boot from the USB on the laptop and follow the update prompts. -## Flashing Heads +## Disassembly First, disconnect the power cable from your device then begin removing the back panel by removing the screws. A guitar pick or an old credit card can be helpful for detaching the panel. @@ -81,12 +106,14 @@ Try to read the name of the SPI flash chip. The dot on the chip helps to identif ![SPI BIOS flash chip closed view]({{ site.baseurl }}/images/T480s/4_bios_chip_orientation.jpg) -First, connect the clip of your chosen SPI programmer (Raspberry Pi Pico was used in the sample commands) to the chip. Next, connect the programmer to the USB port of your other Linux-based computer with flashrom installed. In my setup, the red wire should be where the dot is (the dot indicates pin 1). Here, please also see the flashing guide for the T430. +## Flashing + +First, connect the clip of your chosen SPI programmer (Raspberry Pi Pico was used in the sample commands) to the chip. Next, connect the programmer to the USB port of your other Linux-based computer with flashrom/flashprog installed. In my setup, the red wire should be where the dot is (the dot indicates pin 1). Here, please also see the flashing guide for the T430. -Use flashrom/flashprog to check the chip you are connected to: +Use `[flasher]` of your choice (flashrom or flashprog -- see [Tool Interchangeability]({{ site.baseurl }}/SPI-Programmer-Best-Practices/#tool-interchangeability)) with the programmer you selected ([programmer] -- see [Programmer Selection]({{ site.baseurl }}/SPI-Programmer-Best-Practices/#programmer-selection)): ```shell -sudo flashprog -p serprog:dev=/dev/ttyACM0:spispeed=16M +sudo [flasher] --programmer [programmer] ``` Here is my output. @@ -104,7 +131,7 @@ No operations were specified. Read from the chip twice (where the name of the flash chip is `YYY`): ```shell -sudo flashprog -r ~/t480s_original_bios.bin --programmer serprog:dev=/dev/ttyACM0:spispeed=16M -c YYY +sudo [flasher] --read ~/t480s_original_bios.bin --programmer [programmer] -c YYY ``` First output can be seen here. @@ -121,7 +148,7 @@ Reading flash... done. ```shell -sudo flashprog -r ~/t480s_original_bios_1.bin --programmer serprog:dev=/dev/ttyACM0:spispeed=16M -c YYY +sudo [flasher] --read ~/t480s_original_bios_1.bin --programmer [programmer] -c YYY ``` Second output can be seen here. @@ -138,7 +165,7 @@ Reading flash... done. Make sure that the dump matches the chip content. If this is the case, the output of the following command will state `Verifying flash... VERIFIED` ```shell -sudo flashprog -v ~/t480_original_bios.bin --programmer serprog:dev=/dev/ttyACM0:spispeed=16M -c YYY +sudo [flasher] --verify ~/t480_original_bios.bin --programmer [programmer] -c YYY ``` Make sure that files do not differ. @@ -168,7 +195,7 @@ If the files differ or the chip content does not match the dump, try reconnectin If they are the same, then write `t480s-hotp-maximized.rom` to the SPI flash chip: ```shell -sudo flashprog -p serprog:dev=/dev/ttyACM0:spispeed=16M -c YYY -w ~/heads/build/x86/t480s-hotp-maximized/heads-t480s-hotp-maximized.rom +sudo [flasher] --programmer [programmer] -c YYY -w ~/heads/build/x86/t480s-hotp-maximized/heads-t480s-hotp-maximized.rom ``` Here is a successful attempt. Be patient, it may take a while. @@ -193,10 +220,11 @@ You should then follow through with [configuring keys]({{ site.baseurl }}/Config ## Flash Thunderbolt firmware Important, ensure that power supply and all batteries, including the CMOS battery, are disconnected. After connecting the clip to the Thunderbolt chip as shown in the figure above read from the chip, making sure the connection is stable. The procedure is similar to the flashing Heads on the SPI chip. Therefore, comments are skipped. +(flashprog can also be used — substitute as in the main section above) Check the chip you are connected to: ```shell -sudo flashprog -p serprog:dev=/dev/ttyACM0:spispeed=16M +sudo [flasher] --programmer [programmer] ``` Output: ``` @@ -210,15 +238,15 @@ No operations were specified. ``` ```shell -sudo flashrom --programmer [programmer] --read ~/t480s_original_tb.bin --chip YYY +sudo [flasher] --programmer [programmer] --read ~/t480s_original_tb.bin --chip YYY ``` ```shell -sudo flashrom --programmer [programmer] --read ~/t480s_original_tb_1.bin --chip YYY +sudo [flasher] --programmer [programmer] --read ~/t480s_original_tb_1.bin --chip YYY ``` ```shell -sudo flashrom --programmer [programmer] --verify ~/t480s_original_tb.bin --chip YYY +sudo [flasher] --programmer [programmer] --verify ~/t480s_original_tb.bin --chip YYY ``` ```shell @@ -233,6 +261,6 @@ diff <(hexdump -C t480_original_tb.bin) <(hexdump -C t480_original_tb_1.bin) Flash the padded Thunderbolt firmware. The firmware file tb.bin is located in the blobs folder after you build the Heads locally, or in the CircleCI artifacts. ```shell -sudo flashrom --programmer [programmer] --chip YYY --write ~/t480s_tb.bin +sudo [flasher] --programmer [programmer] --chip YYY --write ~/t480s_tb.bin ``` Done. diff --git a/Installing-and-Configuring/Flashing-Guides/T530-maximized.md b/Installing-and-Configuring/Flashing-Guides/T530-maximized.md new file mode 100644 index 0000000..d3c9ece --- /dev/null +++ b/Installing-and-Configuring/Flashing-Guides/T530-maximized.md @@ -0,0 +1,82 @@ +--- +layout: default +title: Lenovo T530 Maximized +permalink: /T530-maximized-flashing/ +nav_order: 9 +parent: Step 2 - Flashing Guides +grand_parent: Installing and configuring +--- + +Lenovo T530 (Maximized) +=== + +
+ + Table of contents + + {: .text-delta } +1. TOC +{:toc} +
+ +## ⚠️ EOL: No microcode updates +{: .warning } +This board's CPU generation has reached End of Servicing Updates. +See [per-board EOL/ESU status](https://github.com/linuxboot/heads/blob/master/doc/BOARDS_AND_TESTERS.md#per-board-eolesu-status) +for ESU dates and [Heads threat model]({{ site.baseurl }}/Heads-threat-model/#binary-blobs-microcode-updates-and-transient-execution-vulnerabilities) +for security implications. + +## ✅ PROTECTED: TPM GPIO Reset +{: .warning } +Pre-Skylake — dedicated PLTRST# pin. +See [Per-Board Protection Status]({{ site.baseurl }}/Heads-threat-model/#per-board-protection-status), +[TPM GPIO Reset Vulnerability](https://github.com/linuxboot/heads/blob/master/doc/TPM_GPIO_Reset_Vulnerability.md). + +## ⚡ Safety First +**Before starting, please read our [SPI Programmer Best Practices guide]({{ site.baseurl }}/SPI-Programmer-Best-Practices/) for essential safety information and programmer recommendations.** + +## Disassembly +The T530 shares the same board and SPI layout as the W530. See: + +→ **[Coreboot W530/T530 documentation](https://doc.coreboot.org/mainboard/lenovo/w530.html)** (dual SPI flash, /CS sharing trick) +→ **[Lenovo Ivy Bridge series](https://doc.coreboot.org/mainboard/lenovo/Ivy_Bridge_series.html)** (8MB + 4MB, socketed=no) +→ **[Internal flashing](https://doc.coreboot.org/mainboard/lenovo/ivb_internal_flashing.html)** (SMM_BWP/BLE exploit for BIOS < 2014) +→ **[ThinkPad W530/T530 HMM](https://pcsupport.lenovo.com/us/en/products/laptops-and-netbooks/thinkpad-t-series-laptops/thinkpad-t530/downloads/driver-list/component?name=Documentation%2FManuals)** (Hardware Maintenance Manual — shared for T530 and W530) + +The T530 and W530 use a **dual SPI flash** layout (8 MB bottom + 4 MB top), with both chips sharing the same /CS line. The MOSI/MISO lines are linked between the two chips through zero-ohm resistors. When externally flashing one chip, the **other chip's CS# must be pulled HIGH** (to VCC, 3.3V) via a 47 Ω resistor to disable it and prevent bus contention. The same trick is used on the W541 — see the **[libreboot W541 external flashing guide](https://libreboot.org/docs/install/w541_external.html)** for detailed wiring instructions. + +The physical disassembly (keyboard removal, palmrest removal, then flip the board) is the same as the T430 since they share the same chassis family. See the **[T430 disassembly guide]({{ site.baseurl }}/T430-maximized-flashing/#disassembly)** for step-by-step photos. + +On older BIOS versions (pre-2014) with SMM_BWP=0 and BLE=0, **internal flashing** is possible without disassembly — see the coreboot internal flashing link above. + +## Flashing + +The SPI flash layout and flashing commands are the same as the T430. The **top** chip is 4 MB (contains BIOS and reset vector) and the **bottom** chip is 8 MB (contains ME firmware and flash descriptor). + +Before connecting the programmer to either chip, ensure the **other chip's CS# is pulled HIGH** to VCC via a 47 Ω resistor to prevent bus contention. See the libreboot W541 guide above for wiring details. + +Then follow the **[T430 flashing procedure]({{ site.baseurl }}/T430-maximized-flashing/#flashing)** step-by-step: + +Use `[flasher]` of your choice (flashrom or flashprog -- see [Tool Interchangeability]({{ site.baseurl }}/SPI-Programmer-Best-Practices/#tool-interchangeability)) with the programmer you selected ([programmer] -- see [Programmer Selection]({{ site.baseurl }}/SPI-Programmer-Best-Practices/#programmer-selection)): + +```shell +# Identify the chip +sudo [flasher] --programmer [programmer] + +# Read and verify the top (4 MB) chip twice +sudo [flasher] --read ~/top.bin --programmer [programmer] --chip && \ + sudo [flasher] --verify ~/top.bin --programmer [programmer] --chip + +# Write the top ROM +sudo [flasher] --programmer [programmer] --chip --write ~/heads/build/x86/t530-maximized/t530-maximized-top.rom + +# Repeat for the bottom (8 MB) chip +sudo [flasher] --read ~/bottom.bin --programmer [programmer] --chip && \ + sudo [flasher] --verify ~/bottom.bin --programmer [programmer] --chip + +sudo [flasher] --programmer [programmer] --chip --write ~/heads/build/x86/t530-maximized/t530-maximized-bottom.rom +``` + +After flashing, force power off by holding the power button for 10 seconds. Two reboots are sometimes needed after flash since memory training data is wiped. + +Then follow through with **[configuring keys]({{ site.baseurl }}/Configuring-Keys/)**. diff --git a/Installing-and-Configuring/Flashing-Guides/W530-maximized.md b/Installing-and-Configuring/Flashing-Guides/W530-maximized.md new file mode 100644 index 0000000..becf49c --- /dev/null +++ b/Installing-and-Configuring/Flashing-Guides/W530-maximized.md @@ -0,0 +1,82 @@ +--- +layout: default +title: Lenovo W530 Maximized +permalink: /W530-maximized-flashing/ +nav_order: 10 +parent: Step 2 - Flashing Guides +grand_parent: Installing and configuring +--- + +Lenovo W530 (Maximized) +=== + +
+ + Table of contents + + {: .text-delta } +1. TOC +{:toc} +
+ +## ⚠️ EOL: No microcode updates +{: .warning } +This board's CPU generation has reached End of Servicing Updates. +See [per-board EOL/ESU status](https://github.com/linuxboot/heads/blob/master/doc/BOARDS_AND_TESTERS.md#per-board-eolesu-status) +for ESU dates and [Heads threat model]({{ site.baseurl }}/Heads-threat-model/#binary-blobs-microcode-updates-and-transient-execution-vulnerabilities) +for security implications. + +## ✅ PROTECTED: TPM GPIO Reset +{: .warning } +Pre-Skylake — dedicated PLTRST# pin. +See [Per-Board Protection Status]({{ site.baseurl }}/Heads-threat-model/#per-board-protection-status), +[TPM GPIO Reset Vulnerability](https://github.com/linuxboot/heads/blob/master/doc/TPM_GPIO_Reset_Vulnerability.md). + +## ⚡ Safety First +**Before starting, please read our [SPI Programmer Best Practices guide]({{ site.baseurl }}/SPI-Programmer-Best-Practices/) for essential safety information and programmer recommendations.** + +## Disassembly +The W530 shares the same board and SPI layout as the T530. See: + +→ **[Coreboot W530/T530 documentation](https://doc.coreboot.org/mainboard/lenovo/w530.html)** (dual SPI flash, /CS sharing trick) +→ **[Lenovo Ivy Bridge series](https://doc.coreboot.org/mainboard/lenovo/Ivy_Bridge_series.html)** (8MB + 4MB, socketed=no) +→ **[Internal flashing](https://doc.coreboot.org/mainboard/lenovo/ivb_internal_flashing.html)** (SMM_BWP/BLE exploit for BIOS < 2014) +→ **[ThinkPad W530/T530 HMM](https://pcsupport.lenovo.com/us/en/products/laptops-and-netbooks/thinkpad-t-series-laptops/thinkpad-t530/downloads/driver-list/component?name=Documentation%2FManuals)** (Hardware Maintenance Manual — shared for T530 and W530) + +The W530 and T530 use a **dual SPI flash** layout (8 MB bottom + 4 MB top), with both chips sharing the same /CS line. This is the well-known "chip-select sharing trick": the MOSI/MISO lines of the two chips are linked through zero-ohm resistors. When externally flashing one chip, the **other chip's CS# must be pulled HIGH** (to VCC, 3.3V) via a 47 Ω resistor to disable it and prevent bus contention. The same trick is used on the W541 — see the **[libreboot W541 external flashing guide](https://libreboot.org/docs/install/w541_external.html)** for detailed wiring instructions. + +The physical disassembly (keyboard removal, palmrest removal, then flip the board) is the same as the T530 and T430 since they share the same chassis family. See the **[T430 disassembly guide]({{ site.baseurl }}/T430-maximized-flashing/#disassembly)** for step-by-step photos. + +On older BIOS versions (pre-2014) with SMM_BWP=0 and BLE=0, **internal flashing** is possible without disassembly — see the coreboot internal flashing link above. + +## Flashing + +The SPI flash layout and flashing commands are the same as the T430. The **top** chip is 4 MB (contains BIOS and reset vector) and the **bottom** chip is 8 MB (contains ME firmware and flash descriptor). + +Before connecting the programmer to either chip, ensure the **other chip's CS# is pulled HIGH** to VCC via a 47 Ω resistor to prevent bus contention. See the libreboot W541 guide above for wiring details. + +Then follow the **[T430 flashing procedure]({{ site.baseurl }}/T430-maximized-flashing/#flashing)** step-by-step: + +Use `[flasher]` of your choice (flashrom or flashprog -- see [Tool Interchangeability]({{ site.baseurl }}/SPI-Programmer-Best-Practices/#tool-interchangeability)) with the programmer you selected ([programmer] -- see [Programmer Selection]({{ site.baseurl }}/SPI-Programmer-Best-Practices/#programmer-selection)): + +```shell +# Identify the chip +sudo [flasher] --programmer [programmer] + +# Read and verify the top (4 MB) chip twice +sudo [flasher] --read ~/top.bin --programmer [programmer] --chip && \ + sudo [flasher] --verify ~/top.bin --programmer [programmer] --chip + +# Write the top ROM +sudo [flasher] --programmer [programmer] --chip --write ~/heads/build/x86/w530-maximized/w530-maximized-top.rom + +# Repeat for the bottom (8 MB) chip +sudo [flasher] --read ~/bottom.bin --programmer [programmer] --chip && \ + sudo [flasher] --verify ~/bottom.bin --programmer [programmer] --chip + +sudo [flasher] --programmer [programmer] --chip --write ~/heads/build/x86/w530-maximized/w530-maximized-bottom.rom +``` + +After flashing, force power off by holding the power button for 10 seconds. Two reboots are sometimes needed after flash since memory training data is wiped. + +Then follow through with **[configuring keys]({{ site.baseurl }}/Configuring-Keys/)**. diff --git a/Installing-and-Configuring/Flashing-Guides/W541-maximized.md b/Installing-and-Configuring/Flashing-Guides/W541-maximized.md new file mode 100644 index 0000000..c88b555 --- /dev/null +++ b/Installing-and-Configuring/Flashing-Guides/W541-maximized.md @@ -0,0 +1,45 @@ +--- +layout: default +title: Lenovo W541 Maximized +permalink: /W541-maximized-flashing/ +nav_order: 11 +parent: Step 2 - Flashing Guides +grand_parent: Installing and configuring +--- + +Lenovo W541 (Maximized) +=== + +
+ + Table of contents + + {: .text-delta } +1. TOC +{:toc} +
+ +## ⚠️ EOL: No microcode updates +{: .warning } +This board's CPU generation has reached End of Servicing Updates. +See [per-board EOL/ESU status](https://github.com/linuxboot/heads/blob/master/doc/BOARDS_AND_TESTERS.md#per-board-eolesu-status) +for ESU dates and [Heads threat model]({{ site.baseurl }}/Heads-threat-model/#binary-blobs-microcode-updates-and-transient-execution-vulnerabilities) +for security implications. + +## ✅ PROTECTED: TPM GPIO Reset +{: .warning } +Pre-Skylake — dedicated PLTRST# pin. +See [Per-Board Protection Status]({{ site.baseurl }}/Heads-threat-model/#per-board-protection-status), +[TPM GPIO Reset Vulnerability](https://github.com/linuxboot/heads/blob/master/doc/TPM_GPIO_Reset_Vulnerability.md). + +## ⚡ Safety First +**Before starting, please read our [SPI Programmer Best Practices guide]({{ site.baseurl }}/SPI-Programmer-Best-Practices/) for essential safety information and programmer recommendations.** + +## Disassembly +No disassembly photos available yet on any site. References: + +→ **[Libreboot W541 external flashing](https://libreboot.org/docs/install/w541_external.html)** (dual chip, /CS trick: pull other chip CS# high via 47Ω to VCC) +→ **[ThinkPad W541 HMM](https://pcsupport.lenovo.com/us/en/products/laptops-and-netbooks/thinkpad-w-series-laptops/thinkpad-w541/downloads/driver-list/component?name=Documentation%2FManuals)** (Hardware Maintenance Manual — physical disassembly) + +## Flashing +Refer to the T440p guide above for chip location and flashing commands. This guide will be expanded with W541-specific content. diff --git a/Installing-and-Configuring/Flashing-Guides/X220-maximized.md b/Installing-and-Configuring/Flashing-Guides/X220-maximized.md new file mode 100644 index 0000000..48746f7 --- /dev/null +++ b/Installing-and-Configuring/Flashing-Guides/X220-maximized.md @@ -0,0 +1,58 @@ +--- +layout: default +title: Lenovo X220 Maximized +permalink: /X220-maximized-flashing/ +nav_order: 12 +parent: Step 2 - Flashing Guides +grand_parent: Installing and configuring +--- + +Lenovo X220 (Maximized) +=== + +
+ + Table of contents + + {: .text-delta } +1. TOC +{:toc} +
+ +## ⚠️ EOL: No microcode updates +{: .warning } +This board's CPU generation has reached End of Servicing Updates. +See [per-board EOL/ESU status](https://github.com/linuxboot/heads/blob/master/doc/BOARDS_AND_TESTERS.md#per-board-eolesu-status) +for ESU dates and [Heads threat model]({{ site.baseurl }}/Heads-threat-model/#binary-blobs-microcode-updates-and-transient-execution-vulnerabilities) +for security implications. + +## ✅ PROTECTED: TPM GPIO Reset +{: .warning } +Pre-Skylake — dedicated PLTRST# pin. +See [Per-Board Protection Status]({{ site.baseurl }}/Heads-threat-model/#per-board-protection-status), +[TPM GPIO Reset Vulnerability](https://github.com/linuxboot/heads/blob/master/doc/TPM_GPIO_Reset_Vulnerability.md). + +## ⚡ Safety First +**Before starting, please read our [SPI Programmer Best Practices guide]({{ site.baseurl }}/SPI-Programmer-Best-Practices/) for essential safety information and programmer recommendations.** + +## Disassembly + +The X220 has a single 8 MB SPI flash chip located under the palm rest. Disassembly requires keyboard and palm rest removal — similar to the X230. Full disassembly to access the SPI chip is documented in coreboot: + +→ **[Coreboot Sandy Bridge series](https://doc.coreboot.org/mainboard/lenovo/Sandy_Bridge_series.html)** (8MB SPI, in-circuit=yes, socketed=no) +→ **[Coreboot X2xx series disassembly](https://doc.coreboot.org/mainboard/lenovo/x2xx_series.html)** (keyboard + palmrest removal) +→ **[Coreboot T420](https://doc.coreboot.org/mainboard/lenovo/t420.html)** (similar Sandy Bridge disassembly) +→ **[Libreboot X220 external flashing guide](https://libreboot.org/docs/install/x220_external.html)** (disassembly photos, flashing commands) +→ **[X220 Hardware Maintenance Manual](https://pcsupport.lenovo.com/us/en/products/laptops-and-netbooks/thinkpad-x-series-laptops/thinkpad-x220/downloads/driver-list/component?name=Documentation%2FManuals)** + +**Critical**: Remove all batteries (including CMOS) AND disconnect the AC adapter before starting. + +## Flashing + +The X220 uses a single 8 MB SPI flash chip -- no ROM splitting needed. Follow the X230 flashing guide for flashing commands, substituting the X220 board name. Use `[flasher]` of your choice (flashrom or flashprog -- see [Tool Interchangeability]({{ site.baseurl }}/SPI-Programmer-Best-Practices/#tool-interchangeability)) with the programmer you selected ([programmer] -- see [Programmer Selection]({{ site.baseurl }}/SPI-Programmer-Best-Practices/#programmer-selection)): + +```shell +sudo [flasher] --programmer [programmer] --chip YYY --write ~/heads/build/x86/x220-maximized/x220-maximized.rom +``` + +See the [SPI Programmer Best Practices]({{ site.baseurl }}/SPI-Programmer-Best-Practices/) for programmer recommendations. diff --git a/Installing-and-Configuring/Flashing-Guides/m900_tower-maximized.md b/Installing-and-Configuring/Flashing-Guides/m900_tower-maximized.md index deaf7b6..04860ff 100644 --- a/Installing-and-Configuring/Flashing-Guides/m900_tower-maximized.md +++ b/Installing-and-Configuring/Flashing-Guides/m900_tower-maximized.md @@ -1,21 +1,47 @@ --- layout: default -title: Lenovo M900 tower PC -permalink: /M900-Tower-flashing/ -nav_order: 5 +title: Lenovo M900 Tower Maximized +permalink: /M900_Tower-maximized-flashing/ +nav_order: 3 parent: Step 2 - Flashing Guides grand_parent: Installing and configuring --- -Lenovo M900 Tower PC (Maximized) +Lenovo M900 Tower (Maximized) === +
+ + Table of contents + + {: .text-delta } +1. TOC +{:toc} +
-## ⚠️ Safety First +## ⚠️ EOL: No microcode updates +{: .warning } +This board's CPU generation has reached End of Servicing Updates. +See [per-board EOL/ESU status](https://github.com/linuxboot/heads/blob/master/doc/BOARDS_AND_TESTERS.md#per-board-eolesu-status) +for ESU dates and [Heads threat model]({{ site.baseurl }}/Heads-threat-model/#binary-blobs-microcode-updates-and-transient-execution-vulnerabilities) +for security implications. + +## 🛡️ VULNERABLE: TPM GPIO Reset +{: .critical } + +TPMTOTP/HOTP bypassable. Disk encryption with passphrase unaffected. +See [Per-Board Protection Status]({{ site.baseurl }}/Heads-threat-model/#per-board-protection-status), +[TPM GPIO Reset Vulnerability](https://github.com/linuxboot/heads/blob/master/doc/TPM_GPIO_Reset_Vulnerability.md). + + + +## ⚡ Safety First **Before starting, please read our [SPI Programmer Best Practices guide]({{ site.baseurl }}/SPI-Programmer-Best-Practices/) for essential safety information and programmer recommendations.** **Board Information/caveats:** Please read the board information file in the main heads repository before proceeding. +## Disassembly + The M900 Tower is a desktop PC. Access to the board is much easier than on most laptops: remove the side cover and, if necessary, move or remove the drive cage or cables that block access to the SPI flash chip. The machine normally has one main SPI flash chip. On M900-class boards this is usually a 16 MiB SOIC-8 chip containing the firmware descriptor, GBE, Intel ME, and BIOS region. @@ -29,9 +55,6 @@ For whole procedure you will need: - Other laptop/PC with a Linux-based OS installed. -## Flashing Heads - -First, shut down the computer and disconnect the AC power cable. Remove all external cables from the machine. Press the power button for several seconds to discharge residual power. Remove the side cover according to the [M900 Tower Hardware Maintenance Manual](https://download.lenovo.com/pccbbs/thinkcentre_pdf/m800_m900_sff_hmm.pdf) After removing the side cover, remove the CMOS battery. Next, identify the motherboard and the SPI flash chip. If cables or drive cages block access, move them carefully and document where each cable was connected. @@ -45,40 +68,42 @@ You should [download]({{ site.baseurl }}/Downloading) or build (please see [gene Try to read the name of the SPI flash chip. The dot on the chip helps to identify the correct clip orientation. - Next, connect the clip of your SPI programmer to the chip (see the [SPI Programmer Best Practices guide]({{ site.baseurl }}/SPI-Programmer-Best-Practices/) for recommended hardware and example commands). Next, connect the programmer to the USB port of your other Linux-based computer with flashrom installed. In this setup, the red wire should be where the dot is (the dot indicates pin 1). Here, please also see the flashing guide for the T430, T480. + Next, connect the clip of your SPI programmer to the chip (see the [SPI Programmer Best Practices guide]({{ site.baseurl }}/SPI-Programmer-Best-Practices/) for recommended hardware and example commands). Next, connect the programmer to the USB port of your other Linux-based computer with flashrom/flashprog installed. In this setup, the red wire should be where the dot is (the dot indicates pin 1). Here, please also see the flashing guide for the T430, T480. ![Board overview]({{ site.baseurl }}/images/m900_tower/spi_connected.jpeg) + + +## Flashing - Use flashrom to check the chip you are connected to: - Alternatively, use flashprog as described in T480s guide. +Use `[flasher]` of your choice (flashrom or flashprog -- see [Tool Interchangeability]({{ site.baseurl }}/SPI-Programmer-Best-Practices/#tool-interchangeability)) with the programmer you selected ([programmer] -- see [Programmer Selection]({{ site.baseurl }}/SPI-Programmer-Best-Practices/#programmer-selection)): ```shell -sudo flashrom --programmer +sudo [flasher] --programmer [programmer] ``` Create a backup and verify it (where the name of the flash chip is `YYY`): ```shell -sudo flashrom --programmer [programmer] --read ~/m900_tower_original_bios.bin --chip YYY +sudo [flasher] --programmer [programmer] --read ~/m900_tower_original_bios.bin --chip YYY # Quick sanity check: inspect the start of the dump for obvious garbage hexdump -C ~/m900_tower_original_bios.bin | head -20 -sudo flashrom --programmer [programmer] --verify ~/m900_tower_original_bios.bin --chip YYY +sudo [flasher] --programmer [programmer] --verify ~/m900_tower_original_bios.bin --chip YYY ``` ```shell -sudo flashrom --programmer [programmer] --read ~/m900_tower_original_bios_1.bin --chip YYY +sudo [flasher] --programmer [programmer] --read ~/m900_tower_original_bios_1.bin --chip YYY ``` Make sure that the dump matches the chip content. If this is the case, the output of the following command will state `Verifying flash... VERIFIED` ```shell -sudo flashrom --programmer [programmer] --verify ~/m900_tower_original_bios.bin --chip YYY +sudo [flasher] --programmer [programmer] --verify ~/m900_tower_original_bios.bin --chip YYY ``` Make sure that files do not differ. -# If the dumps look consistent, proceed +**If the dumps look consistent, proceed.** Alternative comparison is bit-by-bit. If the files are the same, there should be no output of this command. Otherwise, you will see a bit-by-bit difference between the files. @@ -92,7 +117,7 @@ If the files differ or the chip content does not match the dump, try reconnectin If they are the same, then write `m900_tower-hotp-maximized.rom` to the SPI flash chip. The file name can be different based on the commit you use: ```shell -sudo flashrom --programmer [programmer] --chip YYY --write ~/heads/build/x86/T480-hotp-maximized/T480-hotp-maximized.rom +sudo [flasher] --programmer [programmer] --chip YYY --write ~/heads/build/x86/m900_tower-hotp-maximized/m900_tower-hotp-maximized.rom ``` You should then follow through with [configuring keys]({{ site.baseurl }}/Configuring-Keys/). diff --git a/Installing-and-Configuring/Flashing-Guides/msi_z690a_ddr5-maximized.md b/Installing-and-Configuring/Flashing-Guides/msi_z690a_ddr5-maximized.md new file mode 100644 index 0000000..999ce1e --- /dev/null +++ b/Installing-and-Configuring/Flashing-Guides/msi_z690a_ddr5-maximized.md @@ -0,0 +1,48 @@ +--- +layout: default +title: MSI PRO Z690-A Maximized +permalink: /MSI_Z690A-maximized-flashing/ +nav_order: 14 +parent: Step 2 - Flashing Guides +grand_parent: Installing and configuring +--- + +MSI PRO Z690-A (Maximized) +=== + +
+ + Table of contents + + {: .text-delta } +1. TOC +{:toc} +
+ +## ✅ Active: CPU generation still receiving microcode updates (12th-13th Gen Alder/Raptor Lake) +{: .note } + +Still receiving microcode updates. +See [BOARDS_AND_TESTERS.md](https://github.com/linuxboot/heads/blob/master/doc/BOARDS_AND_TESTERS.md#per-board-eolesu-status), +[Heads threat model]({{ site.baseurl }}/Heads-threat-model/#binary-blobs-microcode-updates-and-transient-execution-vulnerabilities). + +## 🛡️ VULNERABLE: TPM GPIO Reset +{: .critical } + +GPIO lock not enforced at runtime. +See [Per-Board Protection Status]({{ site.baseurl }}/Heads-threat-model/#per-board-protection-status), +[TPM GPIO Reset Vulnerability](https://github.com/linuxboot/heads/blob/master/doc/TPM_GPIO_Reset_Vulnerability.md). + +## ⚡ Safety First + +**Before starting, please read our [SPI Programmer Best Practices guide]({{ site.baseurl }}/SPI-Programmer-Best-Practices/) for essential safety information and programmer recommendations.** + +## Disassembly + +Full disassembly instructions, SPI flash access via JTPM1 header (2mm pitch, requires adapter), SMBIOS data migration procedure, and step-by-step flashing instructions are maintained by [Dasharo](https://docs.dasharo.com/): + +→ **[Dasharo MSI Z690-A documentation](https://docs.dasharo.com/unified/msi/recovery/#ch341a)** + +## Flashing + +For full flashing procedures, see the [Dasharo](https://docs.dasharo.com/) documentation above. diff --git a/Installing-and-Configuring/Flashing-Guides/msi_z790p_ddr5-maximized.md b/Installing-and-Configuring/Flashing-Guides/msi_z790p_ddr5-maximized.md new file mode 100644 index 0000000..3dc009c --- /dev/null +++ b/Installing-and-Configuring/Flashing-Guides/msi_z790p_ddr5-maximized.md @@ -0,0 +1,49 @@ +--- +layout: default +title: MSI PRO Z790-P Maximized +permalink: /MSI_Z790P-maximized-flashing/ +nav_order: 15 +parent: Step 2 - Flashing Guides +grand_parent: Installing and configuring +--- + +MSI PRO Z790-P (Maximized) +=== + +
+ + Table of contents + + {: .text-delta } +1. TOC +{:toc} +
+ +## ✅ Active: CPU generation still receiving microcode updates (12th-14th Gen Alder/Raptor Lake) +{: .note } + +Still receiving microcode updates. +See [BOARDS_AND_TESTERS.md](https://github.com/linuxboot/heads/blob/master/doc/BOARDS_AND_TESTERS.md#per-board-eolesu-status), +[Heads threat model]({{ site.baseurl }}/Heads-threat-model/#binary-blobs-microcode-updates-and-transient-execution-vulnerabilities). + +## 🛡️ VULNERABLE: TPM GPIO Reset +{: .critical } + +GPIO lock not enforced at runtime. +See [Per-Board Protection Status]({{ site.baseurl }}/Heads-threat-model/#per-board-protection-status), +[TPM GPIO Reset Vulnerability](https://github.com/linuxboot/heads/blob/master/doc/TPM_GPIO_Reset_Vulnerability.md). + +## ⚡ Safety First + +**Before starting, please read our [SPI Programmer Best Practices guide]({{ site.baseurl }}/SPI-Programmer-Best-Practices/) for essential safety information and programmer recommendations.** + +## Disassembly + +Full disassembly instructions, SPI flash access via JTPM1 header (2mm pitch, requires adapter), SMBIOS data migration procedure, and step-by-step flashing instructions are maintained by [Dasharo](https://docs.dasharo.com/): + +→ **[Dasharo MSI Z790-P documentation](https://docs.dasharo.com/unified/msi/recovery/#ch341a)** + +## Flashing + + +Key notes: Flash via JTPM1 header (pins 1=Vcc, 7=GND, 5=CS, 6=CLK, 3=MISO, 4=MOSI). SMBIOS UUID/serial must be extracted and re-injected with cbfstool + vboot resign. Disconnect dGPU before flashing. Memory training takes ~2 minutes on first boot. diff --git a/Installing-and-Configuring/Flashing-Guides/nitropad-ns50-maximized.md b/Installing-and-Configuring/Flashing-Guides/nitropad-ns50-maximized.md new file mode 100644 index 0000000..7ff597d --- /dev/null +++ b/Installing-and-Configuring/Flashing-Guides/nitropad-ns50-maximized.md @@ -0,0 +1,50 @@ +--- +layout: default +title: NitroPad NS50 Maximized +permalink: /NS50-maximized-flashing/ +nav_order: 16 +parent: Step 2 - Flashing Guides +grand_parent: Installing and configuring +--- + +NitroPad NS50 (Maximized) +=== + +
+ + Table of contents + + {: .text-delta } +1. TOC +{:toc} +
+ +## ✅ Active: CPU generation still receiving microcode updates (12th Gen Alder Lake-P) +{: .note } + +Still receiving microcode updates. +See [BOARDS_AND_TESTERS.md](https://github.com/linuxboot/heads/blob/master/doc/BOARDS_AND_TESTERS.md#per-board-eolesu-status), +[Heads threat model]({{ site.baseurl }}/Heads-threat-model/#binary-blobs-microcode-updates-and-transient-execution-vulnerabilities). + +## 🛡️ INCONCLUSIVE (unconfirmed): TPM GPIO Reset +{: .warning } + +GPIO lock absent ([Dasharo](https://docs.dasharo.com/)), mode bits hardware-locked; PLTRST# assertion not confirmed on this PCH die per NV4x ADL-P testing. +See [Per-Board Protection Status]({{ site.baseurl }}/Heads-threat-model/#per-board-protection-status), +[TPM GPIO Reset Vulnerability](https://github.com/linuxboot/heads/blob/master/doc/TPM_GPIO_Reset_Vulnerability.md). + +## ⚡ Safety First + +**Before starting, please read our [SPI Programmer Best Practices guide]({{ site.baseurl }}/SPI-Programmer-Best-Practices/) for essential safety information and programmer recommendations.** + +## Disassembly + +Full disassembly photos, SPI chip details (GigaDevice 25B1256EYIG, 32MB WSON-8), programmer setup, and step-by-step flashing instructions are maintained by [Dasharo](https://docs.dasharo.com/): + +→ **[Recovery & disassembly photos](https://docs.dasharo.com/unified/novacustom/recovery/#12th-gen)** +→ **[Initial deployment](https://docs.dasharo.com/unified/novacustom/initial-deployment/#bios-installation)** +→ **[Hardware matrix](https://docs.dasharo.com/variants/novacustom_ns5x_adl/hardware-matrix/)** + +## Flashing + +Key notes: WSON-8 probe required (not SOIC clip). Full binaries required. EC flashed separately via [ite_ec](https://github.com/linuxboot/heads/tree/master/modules/ite_ec). Single-command external flash (`flashrom -p ch341a_spi -w`). diff --git a/Installing-and-Configuring/Flashing-Guides/novacustom-nv4x_adl-maximized.md b/Installing-and-Configuring/Flashing-Guides/novacustom-nv4x_adl-maximized.md new file mode 100644 index 0000000..a4c068e --- /dev/null +++ b/Installing-and-Configuring/Flashing-Guides/novacustom-nv4x_adl-maximized.md @@ -0,0 +1,50 @@ +--- +layout: default +title: NovaCustom NV4x ADL Maximized +permalink: /NV4x_ADL-maximized-flashing/ +nav_order: 17 +parent: Step 2 - Flashing Guides +grand_parent: Installing and configuring +--- + +NovaCustom NV4x ADL (Maximized) +=== + +
+ + Table of contents + + {: .text-delta } +1. TOC +{:toc} +
+ +## ✅ Active: CPU generation still receiving microcode updates (12th Gen Alder Lake-P) +{: .note } + +Still receiving microcode updates. +See [BOARDS_AND_TESTERS.md](https://github.com/linuxboot/heads/blob/master/doc/BOARDS_AND_TESTERS.md#per-board-eolesu-status), +[Heads threat model]({{ site.baseurl }}/Heads-threat-model/#binary-blobs-microcode-updates-and-transient-execution-vulnerabilities). + +## 🛡️ INCONCLUSIVE (unconfirmed): TPM GPIO Reset +{: .warning } + +GPIO lock absent ([Dasharo](https://docs.dasharo.com/)), mode bits hardware-locked; PLTRST# assertion not confirmed on this PCH die per NV4x ADL-P testing. +See [Per-Board Protection Status]({{ site.baseurl }}/Heads-threat-model/#per-board-protection-status), +[TPM GPIO Reset Vulnerability](https://github.com/linuxboot/heads/blob/master/doc/TPM_GPIO_Reset_Vulnerability.md). + +## ⚡ Safety First + +**Before starting, please read our [SPI Programmer Best Practices guide]({{ site.baseurl }}/SPI-Programmer-Best-Practices/) for essential safety information and programmer recommendations.** + +## Disassembly + +Full disassembly photos, SPI chip details (Macronix MX25L25673GZ4I-08G, 32MB WSON-8, 3.3V), programmer setup, and step-by-step flashing instructions are maintained by [Dasharo](https://docs.dasharo.com/): + +→ **[Recovery & disassembly photos](https://docs.dasharo.com/unified/novacustom/recovery/#12th-gen)** +→ **[Initial deployment (two-step flash)](https://docs.dasharo.com/unified/novacustom/initial-deployment/#bios-installation)** +→ **[Hardware matrix](https://docs.dasharo.com/variants/novacustom_nv4x_adl/hardware-matrix/)** + +## Flashing + +Key notes: Intel Boot Guard enabled — external flashing mandatory. Two-step flash (IFD first, then ME+BIOS). Full binaries required. CH341a with WSON-8 probe. diff --git a/Installing-and-Configuring/Flashing-Guides/novacustom-v540tu-maximized.md b/Installing-and-Configuring/Flashing-Guides/novacustom-v540tu-maximized.md new file mode 100644 index 0000000..33a017b --- /dev/null +++ b/Installing-and-Configuring/Flashing-Guides/novacustom-v540tu-maximized.md @@ -0,0 +1,50 @@ +--- +layout: default +title: NovaCustom V540TU Maximized +permalink: /V540TU-maximized-flashing/ +nav_order: 18 +parent: Step 2 - Flashing Guides +grand_parent: Installing and configuring +--- + +NovaCustom V540TU (Maximized) +=== + +
+ + Table of contents + + {: .text-delta } +1. TOC +{:toc} +
+ +## ✅ Active: CPU generation still receiving microcode updates (14th Gen Meteor Lake) +{: .note } + +Still receiving microcode updates. +See [BOARDS_AND_TESTERS.md](https://github.com/linuxboot/heads/blob/master/doc/BOARDS_AND_TESTERS.md#per-board-eolesu-status), +[Heads threat model]({{ site.baseurl }}/Heads-threat-model/#binary-blobs-microcode-updates-and-transient-execution-vulnerabilities). + +## ✅ PROTECTED: TPM GPIO Reset +{: .warning } + +GPIO PLTRST# assertion does not apply to the TPM on this platform. Not vulnerable. +See [Per-Board Protection Status]({{ site.baseurl }}/Heads-threat-model/#per-board-protection-status), +[TPM GPIO Reset Vulnerability](https://github.com/linuxboot/heads/blob/master/doc/TPM_GPIO_Reset_Vulnerability.md). + +## ⚡ Safety First + +**Before starting, please read our [SPI Programmer Best Practices guide]({{ site.baseurl }}/SPI-Programmer-Best-Practices/) for essential safety information and programmer recommendations.** + +## Disassembly + +Full disassembly instructions, SPI chip details (socket-mounted WSON8), programmer recommendations, and step-by-step flashing procedures are maintained by [Dasharo](https://docs.dasharo.com/): + +→ **[Dasharo V540TU documentation](https://docs.dasharo.com/unified/novacustom/recovery/#14th-gen)** +→ **[Dasharo V540TU initial deployment](https://docs.dasharo.com/unified/novacustom/initial-deployment/#bios-installation_1)** +→ **[Dasharo V540TU hardware matrix](https://docs.dasharo.com/variants/novacustom_v540tu/hardware-matrix/)** + +## Flashing + +Key notes: Socket-mounted WSON8 — chip must be physically extracted and re-flashed externally (in-circuit clips not applicable). Two-step flash (IFD first, then ME+BIOS). No full binaries available. EC flashed separately via [ite_ec](https://github.com/linuxboot/heads/tree/master/modules/ite_ec). [Dasharo TrustRoot](https://docs.dasharo.com/glossary/#dasharo-trustroot) (CPU fusing) available — irreversible once enabled. diff --git a/Installing-and-Configuring/Flashing-Guides/novacustom-v560tu-maximized.md b/Installing-and-Configuring/Flashing-Guides/novacustom-v560tu-maximized.md new file mode 100644 index 0000000..73b0a86 --- /dev/null +++ b/Installing-and-Configuring/Flashing-Guides/novacustom-v560tu-maximized.md @@ -0,0 +1,50 @@ +--- +layout: default +title: NovaCustom V560TU Maximized +permalink: /V560TU-maximized-flashing/ +nav_order: 19 +parent: Step 2 - Flashing Guides +grand_parent: Installing and configuring +--- + +NovaCustom V560TU (Maximized) +=== + +
+ + Table of contents + + {: .text-delta } +1. TOC +{:toc} +
+ +## ✅ Active: CPU generation still receiving microcode updates (14th Gen Meteor Lake) +{: .note } + +Still receiving microcode updates. +See [BOARDS_AND_TESTERS.md](https://github.com/linuxboot/heads/blob/master/doc/BOARDS_AND_TESTERS.md#per-board-eolesu-status), +[Heads threat model]({{ site.baseurl }}/Heads-threat-model/#binary-blobs-microcode-updates-and-transient-execution-vulnerabilities). + +## ✅ PROTECTED: TPM GPIO Reset +{: .warning } + +GPIO PLTRST# assertion does not apply to the TPM on this platform. Not vulnerable. +See [Per-Board Protection Status]({{ site.baseurl }}/Heads-threat-model/#per-board-protection-status), +[TPM GPIO Reset Vulnerability](https://github.com/linuxboot/heads/blob/master/doc/TPM_GPIO_Reset_Vulnerability.md). + +## ⚡ Safety First + +**Before starting, please read our [SPI Programmer Best Practices guide]({{ site.baseurl }}/SPI-Programmer-Best-Practices/) for essential safety information and programmer recommendations.** + +## Disassembly + +Full disassembly photos, SPI chip details, programmer setup, and step-by-step flashing instructions are maintained by [Dasharo](https://docs.dasharo.com/): + +→ **[Recovery & disassembly photos](https://docs.dasharo.com/unified/novacustom/recovery/#14th-gen)** +→ **[Initial deployment](https://docs.dasharo.com/unified/novacustom/initial-deployment/#bios-installation_1)** +→ **[Hardware matrix](https://docs.dasharo.com/variants/novacustom_v560tu/hardware-matrix/)** + +## Flashing + +Key notes: Socket-mounted WSON8 — physically extract chip. 1.8V CH341a voltage. Two-step flash. [Dasharo TrustRoot](https://docs.dasharo.com/glossary/#dasharo-trustroot) available — irreversible. diff --git a/Installing-and-Configuring/Flashing-Guides/optiplex-7010_9010-maximized.md b/Installing-and-Configuring/Flashing-Guides/optiplex-7010_9010-maximized.md new file mode 100644 index 0000000..6b6b82c --- /dev/null +++ b/Installing-and-Configuring/Flashing-Guides/optiplex-7010_9010-maximized.md @@ -0,0 +1,66 @@ +--- +layout: default +title: Dell Optiplex 7010/9010 Maximized +permalink: /Optiplex_7010_9010-maximized-flashing/ +nav_order: 1 +parent: Step 2 - Flashing Guides +grand_parent: Installing and configuring +--- + +Dell Optiplex 7010/9010 (Maximized) +=== + +
+ + Table of contents + + {: .text-delta } +1. TOC +{:toc} +
+ +## ⚠️ EOL: No microcode updates +{: .warning } +This board's CPU generation has reached End of Servicing Updates. +See [per-board EOL/ESU status](https://github.com/linuxboot/heads/blob/master/doc/BOARDS_AND_TESTERS.md#per-board-eolesu-status) +for ESU dates and [Heads threat model]({{ site.baseurl }}/Heads-threat-model/#binary-blobs-microcode-updates-and-transient-execution-vulnerabilities) +for security implications. + +## ✅ PROTECTED: TPM GPIO Reset +{: .warning } +Pre-Skylake — dedicated PLTRST# pin. +See [Per-Board Protection Status]({{ site.baseurl }}/Heads-threat-model/#per-board-protection-status), +[TPM GPIO Reset Vulnerability](https://github.com/linuxboot/heads/blob/master/doc/TPM_GPIO_Reset_Vulnerability.md). + +## ⚡ Safety First +**Before starting, please read our [SPI Programmer Best Practices guide]({{ site.baseurl }}/SPI-Programmer-Best-Practices/) for essential safety information and programmer recommendations.** + +## Disassembly +The Optiplex 7010/9010 is an Ivy Bridge-era desktop. Open the side panel to access the motherboard — no further disassembly is required (no keyboard, palmrest, or other covers to remove). + +SPI flash is a single **12 MB (Winbond W25Q128JV)** SOIC-8 chip located on the motherboard. The exact position, board photos, and chip markings are documented in the **[libreboot Dell OptiPlex 7010 guide](https://libreboot.org/docs/install/dell7010.html)**. See also the **[coreboot OptiPlex 9010 page](https://doc.coreboot.org/mainboard/dell/optiplex_9010.html)** for board details. + +## Flashing + +The OptiPlex 7010/9010 uses a single 12 MB SPI flash chip (Winbond W25Q128JV), so there is no dual-chip /CS trick to worry about. Connect your SOIC-8 clip to the chip and verify the connection: + +Use `[flasher]` of your choice (flashrom or flashprog -- see [Tool Interchangeability]({{ site.baseurl }}/SPI-Programmer-Best-Practices/#tool-interchangeability)) with the programmer you selected ([programmer] -- see [Programmer Selection]({{ site.baseurl }}/SPI-Programmer-Best-Practices/#programmer-selection)): + +```shell +sudo [flasher] --programmer [programmer] +``` + +Read and verify the existing firmware twice: + +```shell +sudo [flasher] --read ~/backup.bin --programmer [programmer] --chip W25Q128JV && \ + sudo [flasher] --verify ~/backup.bin --programmer [programmer] --chip W25Q128JV +``` + +Write the Heads ROM: + +```shell +sudo [flasher] --programmer [programmer] --chip W25Q128JV --write ~/heads/build/x86/optiplex-7010_9010-maximized/optiplex-7010_9010-maximized.rom +``` + +After flashing, power off and back on. Then follow through with **[configuring keys]({{ site.baseurl }}/Configuring-Keys/)**. diff --git a/Installing-and-Configuring/Flashing-Guides/talos-2-maximized.md b/Installing-and-Configuring/Flashing-Guides/talos-2-maximized.md new file mode 100644 index 0000000..16de5b3 --- /dev/null +++ b/Installing-and-Configuring/Flashing-Guides/talos-2-maximized.md @@ -0,0 +1,46 @@ +--- +layout: default +title: Raptor Talos II Maximized +permalink: /Talos_II-maximized-flashing/ +nav_order: 20 +parent: Step 2 - Flashing Guides +grand_parent: Installing and configuring +--- + +Raptor Talos II (Maximized) +=== + +
+ + Table of contents + + {: .text-delta } +1. TOC +{:toc} +
+ +## ✅ Active: CPU generation still receiving microcode updates (POWER9) +{: .note } +POWER9 platform — still receiving microcode/firmware. See [BOARDS_AND_TESTERS.md](https://github.com/linuxboot/heads/blob/master/doc/BOARDS_AND_TESTERS.md#per-board-eolesu-status), +[Heads threat model]({{ site.baseurl }}/Heads-threat-model/#binary-blobs-microcode-updates-and-transient-execution-vulnerabilities). + +## ✅ PROTECTED: TPM GPIO Reset +{: .warning } +Not an Intel platform — not affected by Intel PCH GPIO reset. +See [Per-Board Protection Status]({{ site.baseurl }}/Heads-threat-model/#per-board-protection-status), +[TPM GPIO Reset Vulnerability](https://github.com/linuxboot/heads/blob/master/doc/TPM_GPIO_Reset_Vulnerability.md). + +## ⚡ Safety First +**Before starting, please read our [SPI Programmer Best Practices guide]({{ site.baseurl }}/SPI-Programmer-Best-Practices/) for essential safety information and programmer recommendations.** + +## Disassembly +The Talos II is a POWER9 workstation/server platform. Flashing is done via the BMC — no physical SPI programmer needed. + +→ **[Dasharo Talos II overview](https://docs.dasharo.com/variants/talos_2/overview/)** +→ **[Dasharo Initial Deployment](https://docs.dasharo.com/variants/talos_2/initial-deployment/)** (BMC flashing, mboxctl emulation) +→ **[Dasharo Hardware Matrix](https://docs.dasharo.com/variants/talos_2/hardware-matrix/)** +→ **[Raptor CS wiki](https://wiki.raptorcs.com/wiki/Talos_II)** (Hostboot firmware, PNOR flashing) +→ **[Raptor CS Firmware Upgrade Quickstart](https://wiki.raptorcs.com/wiki/Firmware_Upgrade_Quickstart)** + +## Flashing +Flashing procedures are maintained by Raptor CS. This guide will be expanded with community-contributed content. diff --git a/Installing-and-Configuring/Flashing-Guides/x230-maximized.md b/Installing-and-Configuring/Flashing-Guides/x230-maximized.md index 70313bb..88af3f1 100644 --- a/Installing-and-Configuring/Flashing-Guides/x230-maximized.md +++ b/Installing-and-Configuring/Flashing-Guides/x230-maximized.md @@ -2,123 +2,153 @@ layout: default title: Lenovo X230 Maximized permalink: /x230-maximized-flashing/ -nav_order: 2 +nav_order: 13 parent: Step 2 - Flashing Guides grand_parent: Installing and configuring --- -Lenovo X230 (Maximized) (applies to all 4mb+8mb SPI chips maximized boards) +Lenovo X230 (Maximized) === +
+ + Table of contents + + {: .text-delta } +1. TOC +{:toc} +
-## ⚠️ Safety First +## ⚠️ EOL: No microcode updates +{: .warning } +This board's CPU generation has reached End of Servicing Updates. +See [per-board EOL/ESU status](https://github.com/linuxboot/heads/blob/master/doc/BOARDS_AND_TESTERS.md#per-board-eolesu-status) +for ESU dates and [Heads threat model]({{ site.baseurl }}/Heads-threat-model/#binary-blobs-microcode-updates-and-transient-execution-vulnerabilities) +for security implications. + +## ✅ PROTECTED: TPM GPIO Reset +{: .warning } + +Pre-Skylake platform — dedicated PLTRST# pin, not GPIO-shared. +See [Per-Board Protection Status]({{ site.baseurl }}/Heads-threat-model/#per-board-protection-status), +[TPM GPIO Reset Vulnerability](https://github.com/linuxboot/heads/blob/master/doc/TPM_GPIO_Reset_Vulnerability.md). + + + +## ⚡ Safety First **Before starting, please read our [SPI Programmer Best Practices guide]({{ site.baseurl }}/SPI-Programmer-Best-Practices/) for essential safety information and programmer recommendations.** [X230 Hardware Maintenance Manual](https://web.archive.org/web/20201112030049/https://thinkpads.com/support/hmm/hmm_pdf/x230_x230i_hmm_en_0b48666_01.pdf) [X230 Tablet Hardware Maintenance Manual](https://web.archive.org/web/20130908100917/http://download.lenovo.com/pccbbs/mobiles_pdf/0b48730.pdf) -![Underside of the x230]({{ site.baseurl }}/images/Underside_of_the_x230.jpg) +## Disassembly + +→ **[Libreboot X230 external flashing guide](https://libreboot.org/docs/install/x230_external.html)** (disassembly photos, dual-chip ROM splitting) +→ **[Ivybridge/Haswell common guide](https://libreboot.org/docs/install/ivy_has_common.html)** (vendor file injection, MAC address, pre-flash checks) + +The X230 has two SPI flash chips: one 4 MB (BIOS + reset vector) and one 8 MB (ME firmware + flash descriptor). The Heads maximized image is a combined ROM that must be split for external flashing: + +```shell +dd if=heads-x230-maximized.rom of=top.rom bs=1M count=4 +dd if=heads-x230-maximized.rom of=bottom.rom bs=1M skip=4 +``` + +Flash the 4 MB chip with `top.rom` and the 8 MB chip with `bottom.rom`. + +### Disassembly steps -**Critical**: Remove the batteries AND disconnect the AC adapter before starting. The Thinkpad x230 has - two SPI flash chips that hold the BIOS, ME, etc. and are located under the - palm rest. To access these chips, first remove the indicated screws on the back - of the laptop. +Start by removing the battery and disconnecting the AC power. Remove all screws from the bottom of the machine marked with a keyboard/touchpad indicator. ![Keyboard tilted up]({{ site.baseurl }}/images/Keyboard_tilted_up.jpg) -Removing these screws will allow you to remove the keyboard and palm rest. +Pry up the keyboard and separate it from the palmrest. The keyboard is connected to the motherboard by a ribbon cable which easily detaches. (The keyboard only needs to be removed so that the palm rest can be removed. After removing the palm rest, you can put the keyboard back.) ![Ribbon cable]({{ site.baseurl }}/images/Ribbon_cable.jpg) -The keyboard is connected to the motherboard by a ribbon cable which easily - detaches from the motherboard. (The keyboard only needs to be removed so that - the palm rest can be removed. After removing the palm rest, you can put the - keyboard back.) +The palm rest is also connected to the motherboard by a ribbon cable held by a small latch. Undo the latch, then lift the palm rest off. -The palm rest is also connected to the motherboard, but there is a little latch - holding its ribbon cable. After undoing that latch, the palm rest should be -fairly easy to remove. - -Pull up the black plastic on the bottom right of the palm rest to reveal the two - SPI flash chips. +Pull up the black plastic cover on the bottom right of the palm rest area to reveal the two SOIC SPI flash chips. ![Flash chips]({{ site.baseurl }}/images/Flash_chips.jpg) -The top chip is 4MB and contains the BIOS and reset vector. The bottom chip is - 8MB and has the [Intel Management Engine (ME)](https://www.flashrom.org/ME) - firmware, plus the flash descriptor. +The top chip (closer to the CPU) is 4 MB — this holds the BIOS and reset vector. The bottom chip is 8 MB and holds the [Intel Management Engine (ME)](https://www.flashrom.org/ME) firmware plus the flash descriptor. -Based on [the work done here](https://github.com/linuxboot/heads/issues/716), - the chips should be one 4M and one 8M of the following: +Based on [the work done here](https://github.com/linuxboot/heads/issues/716), the chips should be one 4M and one 8M of the following: |Vendor|Device| size| |---|---|---| |Eon | EN25QH32 | 4M| |Eon| EN25QH64 | 8M| -|Macronix|MX25L3206E - MX25L3206E/MX25L3208E|4M| -|Macronix|MX25L6405,MX25L6405D, MX25L6406E/MX25L6408E, MX25L6436E/MX25L6445E/MX25L6465E/MX25L6473E/MX25L6473F, MX25L6495F|8M| -|Micron/Numonyx/ST|N25Q032..1E, N25Q032..3E|4M| -|Micron/Numonyx/ST|N25Q064..1E, N25Q064..3E|8M| +|Macronix|MX25L3206E / MX25L3208E|4M| +|Macronix|MX25L6405, MX25L6405D, MX25L6406E / MX25L6408E, MX25L6436E / MX25L6445E / MX25L6465E / MX25L6473E / MX25L6473F, MX25L6495F|8M| +|Micron/Numonyx/ST|N25Q032..1E, N25Q032..3E|4M| +|Micron/Numonyx/ST|N25Q064..1E, N25Q064..3E|8M| |Winbond | W25Q32.V, W25Q32.W | 4M| |Winbond | W25Q64.V, W25Q32.W | 8M| -First [download]({{ site.baseurl }}/Downloading) / [build]({{ site.baseurl }}/x230-maximized-building/) the maximized board roms (top and bottom) for this board and verify their hashes. +### Preparing the ROM + +First [download]({{ site.baseurl }}/Downloading) / [build]({{ site.baseurl }}/x230-maximized-building/) the maximized board ROMs (top and bottom) for this board and verify their hashes. -**Initial BIOS step:** Before attempting ME cleaning or SPI flashing, upgrade the proprietary BIOS to the latest upgradeable vendor release for your platform. For the X230 the latest upgradeable BIOS is **version 2.76** (download: https://download.lenovo.com/pccbbs/mobiles/g2uj32us.iso) installed without EC signature verification; note that newer vendor firmwares may restrict hardware changes (for example, newer versions prevent swapping an X220 keyboard into an X230). If you need to customize the EC firmware while still running proprietary platform firmware, see the **EC firmware & customizations** section in the [Prerequisites]({{ site.baseurl }}/Prerequisites). +**Initial BIOS step:** Before attempting ME cleaning or SPI flashing, upgrade the proprietary BIOS to the latest upgradeable vendor release for your platform. For the X230 the latest upgradeable BIOS is **version 2.76** (download: [g2uj32us.iso](https://download.lenovo.com/pccbbs/mobiles/g2uj32us.iso)) installed without EC signature verification; note that newer vendor firmwares may restrict hardware changes (for example, newer versions prevent swapping an X220 keyboard into an X230). If you need to customize the EC firmware while still running proprietary platform firmware, see the **EC firmware & customizations** section in the [Prerequisites]({{ site.baseurl }}/Prerequisites). **EC note:** For EC reflashing or custom EC behavior (keyboard remaps, battery policies, etc.) see the **EC firmware & customizations** section in the [Prerequisites]({{ site.baseurl }}/Prerequisites) — EC changes should be applied from vendor firmware prior to initial Heads flashing. +## Flashing -Try to read the name on the top SPI flash chip. Then, connect the clip and - SPI programmer to the top SPI flash chip. +### Flashing the top (4 MB) chip + +Try to read the name on the top SPI flash chip. Then, connect the clip and SPI programmer to the top SPI flash chip. **Note**: See the [SPI Programmer Best Practices]({{ site.baseurl }}/SPI-Programmer-Best-Practices/) for programmer recommendations (Tigard recommended; CH347F preferred budget option; CH341A rev1.6+ acceptable with a physical selector). The commands below use `[programmer]` as a placeholder; see the SPI Programmer Best Practices guide for example commands for specific programmers. -Use flashrom to check the chip that you are connected to: +Use `[flasher]` of your choice (flashrom or flashprog -- see [Tool Interchangeability]({{ site.baseurl }}/SPI-Programmer-Best-Practices/#tool-interchangeability)) with the programmer you selected ([programmer] -- see [Programmer Selection]({{ site.baseurl }}/SPI-Programmer-Best-Practices/#programmer-selection)): ```shell -sudo flashrom --programmer [programmer] +sudo [flasher] --programmer [programmer] ``` Find the chip and create a backup and verify it (For me the SPI flash chip is `YYY`): ```shell -sudo flashrom --programmer [programmer] --read ~/top.bin --chip YYY +sudo [flasher] --programmer [programmer] --read ~/top.bin --chip YYY # Quick sanity check: inspect the start of the dump for obvious garbage hexdump -C ~/top.bin | head -20 -sudo flashrom --programmer [programmer] --verify ~/top.bin --chip YYY +sudo [flasher] --programmer [programmer] --verify ~/top.bin --chip YYY ``` If the files differ then try reconnecting your programmer to the SPI flash chip - and make sure your flashrom software is up to date. + and make sure your flashrom/flashprog software is up to date. If they are the same then write `x230-maximized-top.rom` to the SPI flash chip: ```shell -sudo flashrom --programmer [programmer] --chip "YYY" --write ~/heads/build/x86/x230-maximized/x230-maximized-top.rom +sudo [flasher] --programmer [programmer] --chip "YYY" --write ~/heads/build/x86/x230-maximized/x230-maximized-top.rom ``` +### Flashing the bottom (8 MB) chip + Try to read the name on the bottom SPI flash chip. Then, connect the clip and - SPI programmer to the bottom SPI flash chip. Use flashrom to check the chip - that you are connected to: + SPI programmer to the bottom SPI flash chip. Use `[flasher]` (flashrom or flashprog -- see [Tool Interchangeability]({{ site.baseurl }}/SPI-Programmer-Best-Practices/#tool-interchangeability)) to check the chip + that you are connected to: ```shell -sudo flashrom --programmer [programmer] +sudo [flasher] --programmer [programmer] ``` Find the chip and create a backup and verify it (For me the SPI flash chip is `ZZZ`): ```shell -sudo flashrom --programmer [programmer] --read ~/bottom.bin --chip ZZZ +sudo [flasher] --programmer [programmer] --read ~/bottom.bin --chip ZZZ # Quick sanity check: inspect the start of the dump for obvious garbage hexdump -C ~/bottom.bin | head -20 -sudo flashrom --programmer [programmer] --verify ~/bottom.bin --chip ZZZ +sudo [flasher] --programmer [programmer] --verify ~/bottom.bin --chip ZZZ ``` The 8M bottom chip contains the ME firmware. It is neutralized in maximized version. You can flash it specifying the same chip you found under ZZZ: ```shell -sudo flashrom --programmer [programmer] --chip "ZZZ" --write ~/heads/build/x86/x230-maximized/x230-maximized-bottom.rom +sudo [flasher] --programmer [programmer] --chip "ZZZ" --write ~/heads/build/x86/x230-maximized/x230-maximized-bottom.rom ``` diff --git a/Installing-and-Configuring/Flashing-Guides/z220-cmt-maximized.md b/Installing-and-Configuring/Flashing-Guides/z220-cmt-maximized.md new file mode 100644 index 0000000..8d91c9c --- /dev/null +++ b/Installing-and-Configuring/Flashing-Guides/z220-cmt-maximized.md @@ -0,0 +1,70 @@ +--- +layout: default +title: HP Z220 CMT Maximized +permalink: /Z220_CMT-maximized-flashing/ +nav_order: 2 +parent: Step 2 - Flashing Guides +grand_parent: Installing and configuring +--- + +HP Z220 CMT (Maximized) +=== + +
+ + Table of contents + + {: .text-delta } +1. TOC +{:toc} +
+ +## ⚠️ EOL: No microcode updates +{: .warning } +This board's CPU generation has reached End of Servicing Updates. +See [per-board EOL/ESU status](https://github.com/linuxboot/heads/blob/master/doc/BOARDS_AND_TESTERS.md#per-board-eolesu-status) +for ESU dates and [Heads threat model]({{ site.baseurl }}/Heads-threat-model/#binary-blobs-microcode-updates-and-transient-execution-vulnerabilities) +for security implications. + +## ✅ PROTECTED: TPM GPIO Reset +{: .warning } +Pre-Skylake — dedicated PLTRST# pin. +See [Per-Board Protection Status]({{ site.baseurl }}/Heads-threat-model/#per-board-protection-status), +[TPM GPIO Reset Vulnerability](https://github.com/linuxboot/heads/blob/master/doc/TPM_GPIO_Reset_Vulnerability.md). + +## ⚡ Safety First + +**Before starting, please read our [SPI Programmer Best Practices guide]({{ site.baseurl }}/SPI-Programmer-Best-Practices/) for essential safety information and programmer recommendations.** + +## Disassembly + +The Z220 CMT is an Ivy Bridge-era workstation desktop (C216 PCH, same as Z220 SFF). SPI flash is a single **16 MB SOIC-16** chip. The closest coreboot documentation is for the [Z220 SFF variant](https://doc.coreboot.org/mainboard/hp/z220_sff.html) (same PCH, same flash layout). See the [HP service manual](https://h10032.www1.hp.com/ctg/Manual/c04205252.pdf) for CMT-specific system board layout. + +For SOIC-16 clip and programmer recommendations, see our **[SPI Programmer Best Practices]({{ site.baseurl }}/SPI-Programmer-Best-Practices/)** guide. + +## Flashing + +The Z220 CMT uses a single 16 MB SPI flash chip (SOIC-16), so there is no dual-chip /CS trick. Open the side panel, locate the flash chip on the motherboard according to the service manual, and connect your SOIC-16 programming clip. + +Verify the connection: + +Use `[flasher]` of your choice (flashrom or flashprog -- see [Tool Interchangeability]({{ site.baseurl }}/SPI-Programmer-Best-Practices/#tool-interchangeability)) with the programmer you selected ([programmer] -- see [Programmer Selection]({{ site.baseurl }}/SPI-Programmer-Best-Practices/#programmer-selection)): + +```shell +sudo [flasher] --programmer [programmer] +``` + +Read and verify the existing firmware twice: + +```shell +sudo [flasher] --read ~/backup.bin --programmer [programmer] --chip && \ + sudo [flasher] --verify ~/backup.bin --programmer [programmer] --chip +``` + +Write the Heads ROM: + +```shell +sudo [flasher] --programmer [programmer] --chip --write ~/heads/build/x86/z220-cmt-maximized/z220-cmt-maximized.rom +``` + +After flashing, power off and back on. Then follow through with **[configuring keys]({{ site.baseurl }}/Configuring-Keys/)**. diff --git a/Installing-and-Configuring/RecoveryShell.md b/Installing-and-Configuring/RecoveryShell.md index a95e203..b7eae28 100644 --- a/Installing-and-Configuring/RecoveryShell.md +++ b/Installing-and-Configuring/RecoveryShell.md @@ -8,6 +8,10 @@ has_toc: false parent: Installing and configuring --- +{: .note } +The authoritative recovery shell reference is maintained in the source repository: +[doc/recovery-shell.md](https://github.com/linuxboot/heads/blob/master/doc/recovery-shell.md). + Heads Recovery Shell ==== @@ -74,13 +78,6 @@ This example may work for you by changing only the root= setting. Normally, the kexec-boot -b /boot -e ‘foo|elf|kernel /vmlinuz|initrd /initrd.img|append root=/dev/whatever’ -### sign files - -Content in /boot is hashed and recorded in a file. The hashes are signed using the security dongle paired with Heads. These hashes are verified on boot using the public key corresponding to the security dongle. - - mount /dev/sdaX /boot - kexec-sign-config -p /boot - ### hotp and totp Will not work in recovery shell due to missing secrets. See [Limitations](#limitations). diff --git a/index.md b/index.md index b5e8a6f..b0b4c60 100644 --- a/index.md +++ b/index.md @@ -133,7 +133,7 @@ Papers * [2026 - Open Source Summit India - Manish Baing, Arun Mahendran (Lenovo) - An Introduction to Coreboot and LinuxBoot: Building Modern Open Boot Stack](https://ossindia2026.sched.com/event/2KNFn/an-introduction-to-coreboot-and-linuxboot-building-modern-open-boot-stack-manish-baing-arun-mahendran-lenovo)
Abstract - Manish Baing and Arun Mahendran of Lenovo present the two-layer open boot stack replacing proprietary UEFI. The problem: vendor-locked "black box" UEFI builds derived from EDK II that users cannot inspect or modify; slow security patching where vulnerabilities fixed upstream languish until each vendor ships updates; and a bloated DXE (Driver Execution Environment) loading hundreds of tightly-coupled drivers, slowing boot and expanding the attack surface. Solution: coreboot, created by Ron Minnich in 1999 as LinuxBIOS and renamed in 2008, compiles multiple stages — bootblock (assembly, Cache-As-RAM setup), verstage (root of trust for verified boot), romstage (DRAM init), postcar (teardown CAR), ramstage (PCI, CPU, device init, hardware lockdown, write-protects boot media), and payload — into a CBFS image with LZMA compression, typically integrating vendor FSP (FSP-T/M/S) binaries for silicon init. coreboot distributions include Heads (Linux payload with TPM-based measured boot), Libreboot, Canoeboot, MrChromebox, Skulls, and Dasharo. LinuxBoot, started as NERF at Google in 2017, replaces UEFI DXE modules with a minimal Linux kernel and a Go-based initramfs built via u-root (source mode with on-the-fly Go compilation, or BusyBox mode producing one static binary), plus SystemBoot bootloaders (pxeboot for network boot via DHCP/HTTP, boot for finding local kernels) using kexec to hand off to the production OS. Build steps: git clone coreboot, make menuconfig, make to produce build/coreboot.rom; for LinuxBoot, go install u-root, generate initrd.cpio, verify dependencies (uuid-dev, nasm, acpica-tools), build with CONFIG_EFI_BDS, run make to produce build/$(BOARD)/linuxboot.rom. QEMU demo: qemu-system-x86_64 -machine q35 -nographic -kernel vmlinuz -initrd u-root.cpio.xz. + Manish Baing and Arun Mahendran of Lenovo present the two-layer open boot stack replacing proprietary UEFI. The problem: vendor-locked "black box" UEFI builds derived from EDK II that users cannot inspect or modify; slow security patching where vulnerabilities fixed upstream languish until each vendor ships updates; and a bloated DXE (Driver Execution Environment) loading hundreds of tightly-coupled drivers, slowing boot and expanding the attack surface. Solution: coreboot, created by Ron Minnich in 1999 as LinuxBIOS and renamed in 2008, compiles multiple stages — bootblock (assembly, Cache-As-RAM setup), verstage (root of trust for verified boot), romstage (DRAM init), postcar (teardown CAR), ramstage (PCI, CPU, device init, hardware lockdown, write-protects boot media), and payload — into a CBFS image with LZMA compression, typically integrating vendor FSP (FSP-T/M/S) binaries for silicon init. coreboot distributions include Heads (Linux payload with TPM-based measured boot), Libreboot, Canoeboot, MrChromebox, Skulls, and [Dasharo](https://docs.dasharo.com/). LinuxBoot, started as NERF at Google in 2017, replaces UEFI DXE modules with a minimal Linux kernel and a Go-based initramfs built via u-root (source mode with on-the-fly Go compilation, or BusyBox mode producing one static binary), plus SystemBoot bootloaders (pxeboot for network boot via DHCP/HTTP, boot for finding local kernels) using kexec to hand off to the production OS. Build steps: git clone coreboot, make menuconfig, make to produce build/coreboot.rom; for LinuxBoot, go install u-root, generate initrd.cpio, verify dependencies (uuid-dev, nasm, acpica-tools), build with CONFIG_EFI_BDS, run make to produce build/$(BOARD)/linuxboot.rom. QEMU demo: qemu-system-x86_64 -machine q35 -nographic -kernel vmlinuz -initrd u-root.cpio.xz.
Slides: [pptx](https://hosted-files.sched.co/ossindia2026/68/An%20Introduction%20to%20coreboot%20and%20LinuxBoot_v3.pptx)