Platform blobs, collaborators/maintainers/testers for faster problems resolution

[tlaurion]

Coreboot specs

Intel

xxx0: gm45 bridge, Montevina: no FSP, no ME: X200, T400, T500, R500, X300 : no QubesOS support there (no proper vt-d2) 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

Additional required Intel blobs:

FSP is present in all Broadwell+ platforms MRC: Memory Reference Code blob required in Broadwell+ (T440p/w541) : follow ongoing coreboot Native Ram Initialization (NRI effort)

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

AMD fam15h (eg: kgpe-d16) PSP in all models after 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.

[snmcmillan]

t430: @flawedworld is the owner of the current PR and is the one that actually owns a T430.

[flawedworld]

@tlaurion happy with the T430, I also have an X230

[techge]

Actually, I only have two x220 here. Unfortunately, I do not have a T420.

[MrChromebox]

I have:

• Librem 13v2
• Librem 13v4
• Librem 15v3
• Librem 15v4
• x230

[ThePlexus]

x230 and x220 here. Im also waiting for when we roll to next coreboot version to maintain/support p8h61m-pro desktop

[Tonux599]

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.

[Thrilleratplay]

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.

[MrChromebox]

Librem 13v4 (skylake): @MrChromebox Librem 15v4 (skylake): @MrChromebox

those two boards are Kabylake, not skylake

[tlaurion]

@MrChromebox @Thrilleratplay OP modified. Thanks

[Thrilleratplay]

@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.

[tlaurion]

On CBFS region, neutering ME, expending BIOS region in IFD after having reduced ME region

[bwachter]

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.

[blobless]

I have an X230 and a KGPE-D16.

[irelativism]

also have a T60 and macbook 1.1 and 2.1 boards, this is a diferent chipset though nontheless suported by coreboot.

[tlaurion]

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.

[natterangell]

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.

[tlaurion]

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!

[ThePlexus]

@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

[tlaurion]

@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?

[ThePlexus]

@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.

[eganonoa]

@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]

@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.

[tlaurion]

@natterangell A PR while tagging board owners in it (from top post) should do it, not the other way around!

[natterangell]

Makes sense :) Done!

[snmcmillan]

@tlaurion Can you remove me from all the devices listed here? I will not have access to those devices for the foreseeable future.

[flawedworld]

I no longer own any of the hardware mentioned here as it is not getting security coverage from Intel.

[tlaurion]

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

[flawedworld]

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.

[tlaurion]

@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?

[natterangell]

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 😊

[flawedworld]

@flawedworld have you read this ?

So I've just read this. The case of manufacturing mode opens up the can of worms of OEM's being incompetent, where ultimately the truth is that if you want secure hardware as a consumer, you either buy Apple, Google or Microsoft hardware. It doesn't make sense to disable the ME when it is offering security functionality. Things like TXT, SGX, PTT, Boot Guard and so on all depend on it. A secure platform should taking advantage of all of that, and should not be disabling the ME and having nothing. Really my key thoughts from that article are that awareness in firmware security is very poor across the industry and it's good to see government organizations and vendors push for improvements across the board (e.g. Microsoft's Project Mu, Defender Firmware Protection and so on).

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 that there should be a clear and to the point statement explaining that once vendor support is gone (support timelines are a whole other topic) the platform is no longer secure and should be abandoned. It's wrong to see a vendor unsupported platform as secure, it means that platform will not be getting security coverage from the vendor, and may not be mentioned in some or all future security reports. Whilst there are hypervisor mitigations possible for some of the public microarchitectural issues such as SRBDS, the boot has got to be firm on this point and state openly that users should move to a more modern, vendor supported platform as soon as they can. A mitigation in the OS/Hypervisor is not a solution and is not even necessarily effective, secure or even possible at the end of the day and the only sustainable approach is to apply microcode patches/blobs/firmware updates/etc and follow vendor advice or move platform.

[eganonoa]

I would suggest that the decision-making isn't anywhere near as binary as @flawedworld has said or nearly as easy as saying something like "once vendor support is gone (support timelines are a whole other topic) the platform is no longer secure and should be abandoned." First, that presupposes that the platform that was supported was actually secure in the first place, which of course raises trust questions re the vendor and the state in which the vendor is located. Second, (and much more importantly) you have to think about the people who can best benefit from something like this and the world that they live in. It is unrealistic to think that people who are genuinely under threat and can best make use of something like this are capable of owning devices that are new enough to meet that standard (cost/access), or in the case of chromebooks have anywhere near good-enough access to fast internet to make them usable. Put simply, for very many human rights defenders, human rights organizations and other threatened people around the world, including ones in rich countries, it is not possible to easy provision high-cost devices (e.g. Macs, Surface) or use cloud-centric ones (like Chromebooks). I speak from personal experience on this (unfortunately).

On Sat, Jul 24, 2021 at 12:26 AM flawedworld @.***> wrote:

@flawedworld https://github.com/flawedworld have you read this https://hardenedvault.net/2021/07/16/ciso-seceng_csme.html ?

So I've just read this. The case of manufacturing mode opens up the can of worms of OEM's being incompetent, where ultimately the truth is that if you want secure hardware as a consumer, you either buy Apple, Google or Microsoft hardware. It doesn't make sense to disable the ME when it is offering security functionality. Things like TXT, SGX, PTT, Boot Guard and so on all depend on it. A secure platform should taking advantage of all of that, and should not be disabling the ME and having nothing. Really my key thoughts from that article are that awareness in firmware security is very poor across the industry and it's good to see government organizations and vendors like push for improvements across the board (e.g. Microsoft's Project Mu, Defender Firmware Protection and so on).

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 that there should be a clear and to the point statement explaining that once vendor support is gone (support timelines are a whole other topic) the platform is no longer secure and should be abandoned. It's wrong to see a vendor unsupported platform as secure, it means that platform will not be getting security coverage from the vendor, and may not be mentioned in some or all future security reports. Whilst there are hypervisor mitigations possible for some of the public microarchitectural issues such as SRBDS, the boot has got to be firm on this point and state openly that users should move to a more modern, vendor supported platform as soon as they can. A mitigation in the OS/Hypervisor is not a solution and is not even necessarily effective, secure or even possible at the end of the day and the only sustainable approach is to apply microcode patches/blobs/firmware updates/etc and follow vendor advice or move platform.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/osresearch/heads/issues/692#issuecomment-885973047, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANQ47E6GPQELVJQAXDLQGODTZICDDANCNFSM4LEKPQSA .

[eganonoa]

@tlaurion As discussed happy to be added to the following as a collaborator/maintainer/tester as appropriate:

• x230
• t430 (non-dGPU)
• t520
• t530
• w530

I currently have Heads working on the t520, t530 and w530 (#1059) and would be happy to take the lead on those boards. We have some x230 and t430 (non-dGPU) in reserve that we can use to run tests with. [Edit 5 Dec 2021, this PR has been split into three, one per board: #1073 #1072 #1071).

Please remove me from the x220 list as I no longer have one of those in use with Heads.

[natterangell]

@tlaurion, FWIW I also have an X230i, might as well add me to the list for that laptop too. It’s pretty beat up and mostly functions as a backup machine these days, but I can test ROMs easily on it.

[alex-nitrokey]

@tlaurion please remove me from the list (alex-nitrokey) as I am not in possession of an T430 and I am currently not working for NK.

Kind regards

[zifxify]

I'm in the posession of an w530. You may add me to the list :)

[ghost]

i'm running heads on a w530-dgpu-K2000m, and i still have the t430-dgpu feel free to add me to the w530 group

[weyounsix]

w530-dgpu-K2000m, t430-dgpu, and x230 owner w/ programmer here

[jnscmns]

w530 and x230 - Feel free to add me to the list. Thanks

[tlaurion]

@jnscmns w530 is with dgpu if I recall well, which model?

[jnscmns]

@jnscmns w530 is with dgpu if I recall well, which model?

K1000M

[tlaurion]

@srgrint added you as x220 tester. Please tell me if you want to be removed

[tlaurion]

@3hhh what platforms do you own? Can I add you under OP here as a owner of those platforms?

[3hhh]

On 12/19/22 21:27, tlaurion wrote:

@3hhh what platforms do you own? Can I add you under OP here as a owner of those platforms?

T530, feel free to add me.

I'll look into your other posts once I have some more time.

[aluciani]

T430, X230 feel free to add me

I also have a w541 i have produced a binary but can't decide myself to flash it because i only have one w541 and it's my main workstation. But i have the blobs, the config file, and the w541 is now under coreboot thanks to chromebox edit: about the T430, i'll have one t430 motherboard without dgpu, and on with

[tlaurion]

@techge : just removed you for x220 board, forgot to do so before it seems.

You might want to be check TPM2 qemu support (#1292), and if coreboot supports your new board, you might be interested into collaborating into moving things forward for TPM2 support for newer boards (with more blobs dependencies on coreboot's side for x86 of course).

[techge]

Thank you! And I will for sure try to get things running, if my board will ever be supported by coreboot! It is from an OSS friendly brand, but it does not release coreboot-ready laptops yet - although I thought exactly this when buying the device :grimacing:

[tlaurion]

@ThePlexus I added you in OP for t440p and p8z77-m_pro.

[tlaurion]

@srgrint @akunterkontrolle I added you under t440p under OP. let me know if you want to be removed.

[tlaurion]

@nestire: added you in OP for x230/t430 legacy boards