heads
heads copied to clipboard
linuxboot
Platform blobs, collaborators/maintainers/testers for faster problems resolution
Coreboot specs
Intel
xxx0: gm45 bridge, Montevina: no FSP, no ME: X200, T400, T500, R500, X300 xx20: Sandy bridge, no FSP. ME<10: BUP module required only: X220/T420/T520 xx30: Ivy bridge, no FSP. ME<10: ROMP and BUP required: X230/T430/W530 Z220 CMT and others FSP is present in all more recent models MRC: Memory Reference Code blob required in Broadwell+ (T440p)
ME status on different boards models
Removed in ME <=6 (xxx0) Deactivated+Neutered ME in ME 6 <= 10 (xx20 BUP/xx30 BUP+ROMP) Deactivate+Partially Neutered (BUP, RBE, Kernel and syslibs modules REQUIRED in ME > 11) Soft disable/HAP disable bit possible on ME 12+ (PoC BE CAUTIOUS)
xx30, xx20: ME 6 <= 10 Skylake, Kabylake, Whiskeylake and newer: ME >= 11 Intel ME then changed its name to Converged Security Management Engine (CSME), where HAP bit can be flipped, but modules cannot be removed anymore.
AMD
PSP in all models after fam15h AMD fam15h
Power9
Blobless.
Boards and willing testers
Laptops
x200 (xxx0): @irelativism
t400 (xxx0): @irelativism
r500 (xxx0): @fhvyhjriur
x220 (xx20): @Thrilleratplay @blackmaria @srgrint
t420 (xx20): @alexmaloteaux @natterangell (iGPU) @akfhasodh @doob85
t430 (xx30): @nestire(t430-legacy, t430-maximized) @Thrilleratplay @alexmaloteaux @lsafd @bwachter(iGPU maximized) @shamen123 @eganonoa(iGPU) @nitrosimon @jans23 @icequbes1 (iGPU) @weyounsix (t430-dgpu)
t430-dgpu (xx30): @weyounsix (t430-dgpu)
t520 (xx30): NOBODY
t530 (xx30): @3hhh
w530 (xx30): @eganonoa @zifxify @weyounsix (dGPU: w530-k2000m) @jnscmns (dGPU K1000M) @computer-user123 (w530 / & w530 k2000 : prefers iGPU)
w530-dgpu (xx30): @weyounsix (dGPU: w530-k2000m) @jnscmns (dGPU K1000M) @computer-user123 (w530 / & w530 k2000 : prefers iGPU)
x230 (xx30): @nestire(x230-legacy, x230-maximized) @tlaurion(maximized) @osresearch @merge @jan23 @MrChromebox @shamen123 @eganonoa @bwachter @Thrilleratplay @jnscmns @doob85
X230i (x230): @natterangell
x230-fhd/edp variant: @n4ru @computer-user123 (nitro caster board) @Tonux599 @househead @pcm720 (eDP 4.0 board and 1440p display)
t440p: @ThePlexus @srgrint @akunterkontrolle @rbreslow
w541 (similar to t440p): @resende-gustavo @gaspar-ilom
Librem 11(JasperLake): @JonathonHall-Purism
Librem 13v2 (Skylake): @JonathonHall-Purism
Librem 13v4 (Kabylake): @JonathonHall-Purism
Librem 14 (CometLake): @JonathonHall-Purism
Librem 15v3 (Skylake): @JonathonHall-Purism
Librem 15v4 (Kabylake): @JonathonHall-Purism
Nitropad NS50 (AlderLake) : @daringer
Nitropad NV41 (AlderLake) : @daringer
Servers
coreboot based
kgpe-d16 (AMD fam15h) (dropped in coreboot 4.12): @tlaurion @Tonux599 @zifxify @blobless kcma-d8 AMD fam15h (dropped in coreboot 4.12): @59iosl30 Supermicro x11ssh: @osresearch @citypw @MrChromebox @root-hardenedvault ? Librem L1UM v1 (Broadwell): @JonathonHall-Purism Librem L1Um v2 (CoffeeLake): @JonathonHall-Purism Talos II: @tlaurion
linuxboot based
Leopard OCP node: @osresearch others? Winterfell OCP node: @osresearch others? Intel S2600wf : @osresearch others? r630: @osresearch others?
Desktop
coreboot based
kgpe-d16 AMD fam15h (dropped in coreboot 4.12): @0rb677 @Tonux599 @zifxify @blobless kcma-d8 AMD fam15h (dropped in coreboot 4.12): @59iosl30 Librem Mini (Whiskeylake): @JonathonHall-Purism Librem Mini 2 (Whiskeylake): @JonathonHall-Purism Talos II: @tlaurion ASUS P8Z77 M PRO (Ivy bridge): @ThePlexus HP Z220 CMT (Ivy bridge): @d-wid
Integration/Test
Reproducibility expertise: @osresearch @flammit others? Integration expertise: @tlaurion @osresearch @flammit others @JonathonHall-Purism qemu: @osresearch @flammit others @JonathonHall-Purism Continuous Integration environments: @SergiiDmytruk @tlaurion @Tonux599 ?
Please add where you can help so that you are comfortable being tagged in issues.
t430: @flawedworld is the owner of the current PR and is the one that actually owns a T430.
x230 and x220 here. Im also waiting for when we roll to next coreboot version to maintain/support p8h61m-pro desktop
Happy with kgpe-d16, will be purchasing an additional SPI chip for testing soon as its my main workhorse. Also have an x220 and a FHD modded x230.
I have a dedicated x230 tablet for heads.
Additionally, I have:
- T430
- X220
- X220T
- X230 loose motherboards
and a Carbon X1 Gen1 but haven't have success flashing coreboot on it.
My main machine is a X230 with Nitrocaster FHD mod but that has a fully encrypted drive.
Librem 13v4 (skylake): @MrChromebox Librem 15v4 (skylake): @MrChromebox
those two boards are Kabylake, not skylake
@tlaurion Can you remove the X1 Carbon Gen 1 from my name. Until I can successfully coreboot it, I will not be able to provide any assistant with it and do not want to create any confusion.
I'm mainly on the x230 (with several of them). I have a t430 which I'm currently not flashing due to initial setup issues trying to get to a working version - I do have a spare t430 board+CPU, though, but I need to get my hands on a fan for it first. After that it'd be usable for testing with an external display.
also have a T60 and macbook 1.1 and 2.1 boards, this is a diferent chipset though nontheless suported by coreboot.
also have a T60 and macbook 1.1 and 2.1 boards, this is a diferent chipset though nontheless suported by coreboot.
@irelativism: What are SPI flash sizes please? We cannot imply users to solder/unsolder. Coreboot supports hardware, not payloads of Heads sizes. If I remember well, the T60 is 4mb? maybe even 2mb? And the macbooks?
Edit: T60: Mainboard / ROM chip size = 2048 KB (2 MB) Forget about it.
I have the T420 (with Ivy Bridge CPU), and recently successfully built and installed Heads using t420-hotp-maximized (using it with a NitroKey). I bumped Coreboot to version 4.13 in config, and everything works.
I have the T420 (with Ivy Bridge CPU), and recently successfully built and installed Heads using t420-hotp-maximized (using it with a NitroKey). I bumped Coreboot to version 4.13 in config, and everything works.
@natterangell Added you on list on top post for t420. Thanks!
@natterangell @tlaurion Am I missing something here? but heads wont perform any of the measuring of Ivybridge by just bumping coreboot version in 4.13 as theres no patches for ivy/sandy present. The patch 0030-sandybridge.patch needs to be ported into 4.13 at a minimum . I mean it may compile, install and work, but is heads actually doing anything for @natterangell at this time?
https://github.com/osresearch/heads/tree/master/patches/coreboot-4.13
@shamen123 @natterangell : bumping to 4.13 is enough if coreboot config is changed from CONFIG_MEASURED_BOOT=y to CONFIG_TPM_MEASURED_BOOT=y to get rid of the coreboot 4.8.1 0030-sandybridge.patch
@natterangell : this is what was tested?
@shamen123 @natterangell : bumping to 4.13 is enough if coreboot config is changed from CONFIG_MEASURED_BOOT=y to CONFIG_TPM_MEASURED_BOOT=y to get rid of the coreboot 4.8.1 0030-sandybridge.patch
@natterangell : this is what was tested?
thats my point, the post doesn't seem to imply all steps were done , just a version bump. This may confuse others.
@shamen123 @natterangell : bumping to 4.13 is enough if coreboot config is changed from CONFIG_MEASURED_BOOT=y to CONFIG_TPM_MEASURED_BOOT=y to get rid of the coreboot 4.8.1 0030-sandybridge.patch @natterangell : this is what was tested?
thats my point, the post doesn't seem to imply all steps were done , just a version bump. This may confuse others.
You are absolutely correct, that caused confusion on my part. @natterangell spurred me to try building on coreboot 4.13 for the x230. Is it right that these are the necessary additional steps to use coreboot 4.13 including on xx30 series?
(1) change the relevant board config file to read "export CONFIG_COREBOOT_VERSION=4.13"; (2) change the relevant coreboot config file to read CONFIG_TPM_MEASURED_BOOT=y instead of CONFIG_MEASURED_BOOT=y; (3) for xx30 systems run the download_clean_me.sh script in the xx30 blobs folder.
Is there anything else different that should be done, or is that it?
Sorry, I know this isn't necessarily the right place. But it does make me want to reiterate that I'd be happy to contribute to documentation for x220, x230, t430 over the summer (from August).
@natterangell : this is what was tested?
Yes @tlaurion, that is exactly what I did. I apologize for the confusion @shamen123 @eganonoa, I wasn't aware this would trigger an interest :) For reference, I verified as mentioned here, if this is not as it should be please let me know.
The output from a recovery shell is as follows:
pcrs
PCR-00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-01: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-02: 61 50 0B 29 97 54 8F 70 6E 8F 55 31 ED 10 58 10 59 F3 22 7F
PCR-03: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-04: 8A 6A 96 FD E1 A8 DD 96 27 14 79 DC 40 74 2B 36 AB A3 C2 B3
PCR-05: FD A6 EA 9A 37 19 BD 61 39 83 38 EC 25 67 B2 F5 A3 31 EC A7
PCR-06: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-07: 54 F1 99 95 FC 10 D1 23 0A 8E AD 2D B2 0F 1E 13 E0 14 FD D7
cbmem -1 | grep -B2 -i "pcr 2 measure"
TPM: Extending digest for FMAP: COREBOOT CBFS: cpu_microcode_blob.bin into PCR 2
TPM: command 0x14 returned 0x0
TPM: Digest of FMAP: COREBOOT CBFS: cpu_microcode_blob.bin to PCR 2 measured
--
TPM: Extending digest for FMAP: COREBOOT CBFS: vbt.bin into PCR 2
TPM: command 0x14 returned 0x0
TPM: Digest of FMAP: COREBOOT CBFS: vbt.bin to PCR 2 measured
--
TPM: Extending digest for FMAP: COREBOOT CBFS: fallback/dsdt.aml into PCR 2
TPM: command 0x14 returned 0x0
TPM: Digest of FMAP: COREBOOT CBFS: fallback/dsdt.aml to PCR 2 measured
--
TPM: Extending digest for FMAP: COREBOOT CBFS: fallback/payload into PCR 2
TPM: command 0x14 returned 0x0
TPM: Digest of FMAP: COREBOOT CBFS: fallback/payload to PCR 2 measured
I've attached cbfs output too, as well as the coreboot config file I used (feel free to disregard the ASPM and RAMINIT bits, those are there for some other experimentation).
cbfs.txt
coreboot-t420-hotp-maximized.config.txt
If someone else with a T420 can verify, I'd be happy make a PR.
@natterangell A PR while tagging board owners in it (from top post) should do it, not the other way around!
@tlaurion Can you remove me from all the devices listed here? I will not have access to those devices for the foreseeable future.
I no longer own any of the hardware mentioned here as it is not getting security coverage from Intel.
I no longer own any of the hardware mentioned here as it is not getting security coverage from Intel.
@flawedworld : would you improve that section in regard of the choice you took in changing hardware for microcode support from Intel? https://osresearch.net/Heads-threat-model/#binary-blobs-microcode-updates-and-transient-execution-vulnerabilities
I no longer own any of the hardware mentioned here as it is not getting security coverage from Intel.
@flawedworld : would you improve that section in regard of the choice you took in changing hardware for microcode support from Intel? https://osresearch.net/Heads-threat-model/#binary-blobs-microcode-updates-and-transient-execution-vulnerabilities
If the user does not trust microcode/software/etc from vendor X that they should just not use vendor X. It doesn't make sense to me why a user would continue to use hardware/software from a vendor that they do not trust. I don't consider microcode to be a threat to security as I am already trusting a vendor with their hardware platform and microcode is required for proper secure operation of modern platforms anyway. Microcode updates are part of required maintenance too, and things like the Intel ME or on other Intel platforms, the FSP, also need to be maintained. Even if the ME is neutered or disabled, or whatever method/vocabulary one wishes to use, it is still vulnerable and is a critical part of the firmware that must be maintained. The same applies to any part of a platform be it a Qualcomm mobile phone, an AMD workstation or a POWER9 system. I'm going to be moving to a Microsoft Surface machine partly because of those reasons once I have a need for a portable system again.
@flawedworld have you read this ? Anything that should be added to https://osresearch.net/Heads-threat-model/#binary-blobs-microcode-updates-and-transient-execution-vulnerabilities to clarify other users choices that should follow your decision path?
I think @flawedworld makes a good argument here from one perspective. It reminds me a little of what I’ve seen Daniel Micay say regarding why people should be cautious with LineageOS on discontinued/unsupported android devices and rather stick with something like GrapheneOS on devices that still receive firmware updates from vendor.
That being said, I’m not aware of any critical bug on currently supported Thinkpads that cannot be mitigated as well as for any other vendor supported CPU. Not yet at least. But the entire x86 ecosystem is like a wounded animal due to these bugs. It won’t improve much I fear. I hope we can switch to blob free ARM, POWER or RISC-V within a decade but we’re not there yet. So we have to work with what we have.
The industry has been chasing performance gains by relying heavily on speculative execution, and is now paying the price for that. Intel is very much to blame on their part.
I agree it is rather moot not to trust microcode upgrades for a CPU. But AFAIK the ME firmware can still be upgraded (and then disabled/neutered) even if the platform is not supported in terms of further microcode updates.
Boatloads of end users are still vulnerable to all these bugs because their motherboard OEM doesn’t bother to release BIOS updates with patched microcode or ME updates. Tech savvy users can get around that by getting upgraded ME/CSME from Win-raid or whatever and then patch their own BIOS.
I’m still comfortable with an Ivy Bridge CPU, Coreboot/neutered ME and QubesOS. But if some new bug comes along that cannot be mitigated without a microcode update (which I won’t get from Intel), and said bug can be exploited remotely, or break out from a virtual machine, I’ll have to reconsider like @flawedworld.
I tell relatives to get a Chromebook or an Apple device. It’s just easier and more secure for most people. But that doesn’t fit my threat model 😊