Images for x200, t400, t500, r400, r500, w500

[fhvyhjriur]

It would be great if the 'maximized' images could be added to the build process here: https://app.circleci.com/pipelines/github/tlaurion/heads/636/workflows/20a7c648-5217-4aaa-af8d-d511212a14df/jobs/684/artifacts

The XX00 boards with 8MB SPI Flash chip run fine with vt-d support with coreboot when the CPU have vt-d support(can be swapped on 400 and 500 series when no vt-d support available in the cpu and vt-d needed by user). I mention this because of what is written here: #621 (comment)

It would be great when there could be images build like here: https://www.mirrorservice.org/sites/libreboot.org/release/stable/20160907/rom/grub/

I have read that heads need a 8MB SPI chip here: #873

There are x200, t400, t500, r400, r500, w500 (all those are supported by coreboot) with 8MB SPI chips by default. But its not a huge deal when the SPI-chip is smaller. Then the user can simply get a 16MB SPI chip and put it instead of the one that was there before.

Thanks to the 'maximized' idea that libreboot was following and now also heads get onto recently where you dont need any closed-source crap that was preinstalled on the spi-chips, the old spi-chip can be thrown away without making any backups of it and for example a 16MB SPI chip can be put inside instead where heads-maximized have been installed before inserting it into the spi chip without the need of in-circuit-flashing capability.

At the end there should be simply 8mb and 16mb heads-maximized images for all supported boards. People that have 8mb chips preinstalled can simply flash heads-maximized in circuit and people who have 4mb chips, can get a 16mb chip and replace the 4mb chip with the 16mb one.

[Tonux599]

Building for those boards is certainly possible. However I'm not aware of TPM's being present in certainly a few of them which means they would rely HOTP, which is arguably less secure than TOTP which the TPM provides by measuring the state of firmware very early on in the boot process.

[fhvyhjriur]

Yes, the listed devices have TPM inside. Simple prove is here: https://support.lenovo.com/at/de/downloads/ds001667-intel-integrated-tpm-trusted-platform-module-for-windows-xp-sp2-thinkpad-r400-r500-t400-t400s-t500-w500-w700-w700ds-x200-x200s-x200-tablet-x301

Older Thinkpads like for example the Thinkpad X60 also have TPM: https://review.coreboot.org/c/coreboot/+/13410

x301 can also be supported. It was even tested with heads by the person who have add the coreboot support: https://review.coreboot.org/c/coreboot/+/36093

[Tonux599]

Hmm interesting. I can't see any TPM in, for example, T400 devicetree.cb however I own one of these so will do a little investigating.

[Thrilleratplay]

@Tonux599 @fhvyhjriur I believe this generation only has the hardware for TPM version 1.2 verses TPM V2.0 that exists starting with the xx20 series. It would require coreboot support but my guess is that even if there was support that the key generation would be too different to be supported by Heads.

Additionally, developers with these at least one of devices would be needed.

[tlaurion]

All models linked here are libreboot supported if I recall well. All of those models, but some, do not have 8MB spi flash. If accessible when really searching for them, only some will have 8MB flash maximum (Intel something Pro sticker on palmrest). You could of course replace the SPI flash by soldering, not refraining anyone to propose a PR. But those will have really small community and testers and I would not personally advise doing so, since as you said, no vt-x and no vt-d and flawed. I personally dont't see the point but have a stateless laptop to boot tails, for which dev could be done to remove most of the heavy, unrequired tools if going stateless (cryptsetup, lvm, go back at gpg1) and use heads to boot from usb detached signed iso, verified at each usb boot against distro signing key fused in ROM.

If that is interesting, then g505s could be added. As all rhe boards named here with boards aimed at being stateless, without TPM.

fTPM is a thing. Some of those boards have it. But that would defeat the point, since that software TPM is implemented in ME.... which you are trying to get rid of.

As of maximized boards, they are aimed at maximizing SPI space for boards that are 8MB minimal.

[fhvyhjriur]

I took a random T400 laying around here(0 modifications).
Here is the output:
[ 1.050077] tpm_tis 00:05: 1.2 TPM (device-id 0x1020, rev-id 6)

I can enable in the OEM BIOS intel TXT that enabled VT-x and vt-d. It also writes inside the bios screen that its enabling vt-d.
The cpu is a nothing special Intel P8600.
Output from the 'kvm-ok'-tool:
INFO: /dev/kvm exists
KVM acceleration can be used

vmx is listed in /proc/cpuinfo. Here the detailed output:
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts nopl cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm pti tpr_shadow vnmi flexpriority vpid dtherm
vmx flags : vnmi flexpriority tsc_offset vtpr vapic

Flashrom -p internal:
Found Macronix flash chip "MX25L6405D" (8192 kB, SPI) mapped at physical address 0x00000000ff800000.

@Thrilleratplay i am ready to help by testing random images.

[tlaurion]

It would be great if the 'maximized' images could be added to the build process here: https://app.circleci.com/pipelines/github/tlaurion/heads/636/workflows/20a7c648-5217-4aaa-af8d-d511212a14df/jobs/684/artifacts

They are in master for each commit since merge.

[tlaurion]

Vmx is there on stock and with microcode, while vt-d is vt-d1 not vt-d2 and won't install qubesos because it doesn't permit remapping.

Vt-d1 is not supported by coreboot anyway, patches were never merged and abandoned. There are threads i participated on a way while back on qubesos github issues.

I would also test contributed roms on my x200 and x200t and t400. Just for fun.

[fhvyhjriur]

VT-d2 is just required for qubes-os and not to run heads, right?

Thanks to having TPM and 8MB SPI i think there is nothing stopping heads. The coreboot developer of the x301 seems to have tested it on his device: https://review.coreboot.org/c/coreboot/+/36093

I was asking in the first post
It would be great if the 'maximized' images could be added to the build process here: https://app.circleci.com/pipelines/github/tlaurion/heads/636/workflows/20a7c648-5217-4aaa-af8d-d511212a14df/jobs/684/artifacts

for images like heads-x230-maximized-v0.2.0-973-g863a42b.rom
Images that simply overwrite the whole SPI flash without requiring to care about any preinstalled closed source part from the SPI chip.
Probably then named something like heads-t400-maximized-v0.2.0-973-g863a42b.rom

[tlaurion]

Removing ME removes TPM. Its not a physical TPM on gm45. It's a software TPM implemented in ME.

VPro will give 8mb but without TPM.
No vt-d2 so no QubesOS.
8gb ram max.

https://libreboot.org/docs/hardware/gm45_remove_me.html

[tlaurion]

TPM version 1.2 verses TPM V2.0 that exists starting with the xx20 series.

Heads is based on tpm1.2 as of now. Safeboot work is making steps in supporting TPM2 umder heads, see other tpm2 issues where latest tpm2 PR discusses of the challenges and future required changes in heads totp module for tpm2 remote attestation.

[tlaurion]

Yes, the listed devices have TPM inside. Simple prove is here: https://support.lenovo.com/at/de/downloads/ds001667-intel-integrated-tpm-trusted-platform-module-for-windows-xp-sp2-thinkpad-r400-r500-t400-t400s-t500-w500-w700-w700ds-x200-x200s-x200-tablet-x301

This is the windows driver to communicate with exposed software TPM.

[fhvyhjriur]

When the TPM is disabled when disabling ME, could some HOTP-maximized heads images be made?

[tlaurion]

Yes. As already answered by @Tonux599 with limitations of having flashrom and sha256sum do the truncated measurements, USB subsystem already in kernel and rubber ducky attacks possible (usb keyboard simulation to go onto recovery, change policies and fake measurements results), instead of relying on the TPM to measure prior of the payload being ran and detecting if code path going into recovery console already happened, refusing to unlock disk with Disk Unlock key passphrase on default signed boot path with detached signed /boot digests validation + environment sanity check.

Please see HOTP pull request for differences, risks and limitations in more detail.

x200 t400 are the most acquired gm45 boards of those without ME and without TPM. Pull requests welcome, as always.

[tlaurion]

For information, that was attempted in the past while never merged.

• Support removed in 2018
• PR here (would generalize to both t400 and x200, while other boards would need to be tested where I know nobody having those. So scope would be t400 and x200.)
• HOTP firmware measurements discussions prior of HOTP support without TPM are happening here

I kinda consider this issue as a duplicate (extended) of #878

If you agree @fhvyhjriur, please close issue (since producing images would be consequential of board addition.) and comment there so people know that you are interested, have board(s?) and would be willing to participate to which extent.

[fhvyhjriur]

I am willing to test some and i would buy devices that i dont own now. I have at least one more device that have for sure to be tested - the Thinkpad R500. The R500 differ between the listed. The x301 is nearly same like the x200. The R400 is a T400. The W500 is a T500.
The R500 is a special case so far i know - it does not need the GBE part in the IFD because it does not use a intel Networking chip.

With the first post i asked for board addition to have heads-maximized as a modern Libreboot replacement with the microcode-updates and all the coreboot updates from the last years included and great heads-functionality. I think it would make sense to close the issue when there are the rom downloads for the mentioned boards. I would edit-out each device from the issue name when the .rom file for the device is downloadable. This would be probably the x200 maybe even this month. When the last device from the list get applied, i would close it. This would be about the same procedure like on other reports in this tracker.

[tlaurion]

This would be probably the x200 maybe even this month.

Pull Requests (PR) welcome.

[fhvyhjriur]

There is already this here: 7373d53
I would get a x200 and test a .rom file if you cant or do not want to test it on your x200. Could you let the build server build a image for testing?

[tlaurion]

@fhvyhjriur you can take a look at https://github.com/tlaurion/heads/tree/x200_bringback
If build is successfull, you will have HOTP and TPM less, coreboot using generated ifd and generated gbe from bincfg.

Please fork that PR and bring it further. And don't forget to backup your SPI to be able to revert in case of a brick.

[tlaurion]

• x200-maximized -> PR (WiP) X200-maximized board addition #934, build, direct link to rom
• t400-maximized - > PR xxx0 maximized (t400 x200) #953
• t500-maximized
• r500-maximized
• w500-maximized

[irelativism]

Nice! have you looked into TBM project external TPM like for boot process, there might be some overlap here.

[tlaurion]

@irelativism @fhvyhjriur added you under #692

@irelativism direct link to TBM?

[irelativism]

https://media.ccc.de/v/SHA2017-280-tbm_trusted_boot_module

[tlaurion]

@fhvyhjriur :

With the first post i asked for board addition to have heads-maximized as a modern Libreboot replacement with the microcode-updates and all the coreboot updates from the last years included

retroboot fits better the bill asked here. Heads slightly more secure features are TPM based, enforcing early measured boot. Without a TPM, Heads project is diverging from its goal. In the past, KGPE-D16 was added since TPM slot was there, where TPM support was not and where support was finally added recently in Heads tree with coreboot version bump.

I am not clear about #836 meeting the requirement of Heads as of now (USB Security dongle TPM equivalent requires USB being brought prior of measurements, where HID (keyboard) support can theoretically be used to have a rubber ducky (keyboard + flash memory) to sed (find, replace) text in code, or even copy over Heads files by automated HID keyboard input.
The absence of a Disk Unlock Key released by TPM with it's protection offered by Heads' TPM changing its PCRs when Heads goes into Recovery shell and back into GUI... Heads could be mislead to have replaced flashrom, sha256sum... Heads could lie about its attestation results...) You are more then welcome participating in the discussion over there.

[tlaurion]

Meanwhile, I see support for these boards as being low priority, where the branch linked above for x200 could be taken, modified, and subsequent PRs proposed to fill community member's needs, by one filling's his own needs. This is an open source project, where community members are more then welcome to propose code changes to be brought upstream per their own initiatives, and where others can jump in to fill the gap.

As the porting guide explains, supporting/testing those additional boards mean coreboot config (config/coreboot-x200-maximized.config) should be copied over build/coreboot-/.config, and modified (cd build/coreboot-/, make menuconfig, make changes there until it works for you, then create a new board directory and file, make in point to correspondig coreboot config and modify coreboot config to point to board specified vmlinuz and initrd).

If the porting path is not clear enough, I invite people to open issues, and provide proper changes to wiki-heads project. Once again, taking responsibility of bringing a board and consequent documentation is time consuming, and should be community driven, filling one member's need and providing what worked for him to the community in form of a PR.

@irelativism : did you had any success booting CircleCI's built rom from actual x200-maximized PR?

[tlaurion]

@irelativism

https://media.ccc.de/v/SHA2017-280-tbm_trusted_boot_module

Interesting. Fastforwarded video in absence of bundled paper, and was not able to quickly find the schematics and where the TBM would be plugged on the motherboard, and was not able to see if that could work for xxx0 boards.

If you can point at a t=xxx in the video, or more specific documents here or in an additional issue, that might be of interest for the Head's community (As usable Open TPM (other issue) and other projects with guidance on usability, so that not everyone has to read everything to come to a conclusion: Share your thoughts and insights).

[fhvyhjriur]

retroboot fits better the bill asked here. Heads slightly more secure features are TPM based, enforcing early measured boot.

Nice. Leah is back again https://notabug.org/retroboot/retroboot/commits/master
Thanks for mentioning retroboot.
But yes, i still prefer Heads because of its security additions.

[tlaurion]

ok @fhvyhjriur, added a new branch https://github.com/tlaurion/heads/tree/xxx0-maximized where t400 was added.

Note that https://github.com/tlaurion/heads/blob/xxx0-maximized/boards/t400-maximized/t400-maximized.config#L57 might need to be changed, and t400 disassembled completely to access the SPI flash under the board, which makes the t4xx boards more hard to use as a test board as compared to x2xx boards, where chip is easily accessible.

...And where #947 (downloading tarballs from ftpmirror.gnu.org) is a temporary problem needing fixing (upstream or with some creativity) to have successful builds for everyone.

[tlaurion]

But yes, i still prefer Heads because of its security additions.

@hfhvyhjriur:
Those security features are way lowered down in the absence of a TPM, as stated previously.
Signing /boot config from USB Security dongle's safeguarded private key (where Libreboot permits encrypted /boot), booting ISOs after having verified integrity against Distro public key (Tails as of now in present use case) in ROM are basically the only added security features you get from Heads without a TPM, hence, without measured boot/remote attestation and valid root of trust whatsoever.

[tlaurion]

@fhvyhjriur look at #953 artifacts :)

[fhvyhjriur]

@tlaurion I did the test on T400. It does not boot. More detailed report and probably best place for discussion about this build here #953

[irelativism]

@fhvyhjriur :

With the first post i asked for board addition to have heads-maximized as a modern Libreboot replacement with the microcode-updates and all the coreboot updates from the last years included

retroboot fits better the bill asked here. Heads slightly more secure features are TPM based, enforcing early measured boot. Without a TPM, Heads project is diverging from its goal. In the past, KGPE-D16 was added since TPM slot was there, where TPM support was not and where support was finally added recently in Heads tree with coreboot version bump.

I am not clear about #836 meeting the requirement of Heads as of now (USB Security dongle TPM equivalent requires USB being brought prior of measurements, where HID (keyboard) support can theoretically be used to have a rubber ducky (keyboard + flash memory) to sed (find, replace) text in code, or even copy over Heads files by automated HID keyboard input.
The absence of a Disk Unlock Key released by TPM with it's protection offered by Heads' TPM changing its PCRs when Heads goes into Recovery shell and back into GUI... Heads could be mislead to have replaced flashrom, sha256sum... Heads could lie about its attestation results...) You are more then welcome participating in the discussion over there.

this would be done through miniPCIexpress, but is open so offcourse other connections can happend. So there isnt such problem with USB
Im working on something I call LIBREBOOK a macbok 2.1 board in a aluminium 8.1 chassis, with recented added amd free graphics (5000), all freesoftware and would definitely like to add a TBM so I dont need to use GRUB2 attestation but use kexec.

[tlaurion]

@irelativism not relevant to this issue. Please open new issue.

[tlaurion]

@fhvyhjriur found my vpro x200. Will merge debug requirements in next PR commit

[tlaurion]

@fhvyhjriur found debugging notes in other PR/issues from #953 (comment) down.

[irelativism]

it is relevant @tlaurion given your previous arguments about it being a target and inferior are not valid given it doesnt apply to TBM.

[tlaurion]

@irelativism How is libreboot relevant to this ticket targeting gm45 based boards?

I don't understand your last comment either. Please use more words.

[tlaurion]

TBM = TPM? What is happening through micipciexpress? Please export brain content.

[fhvyhjriur]

I am still interested to test different images. I have already installed coreboot on few of the devices and replaced all the SPI chips with 16mb ones.

[fhvyhjriur]

My interest is still there. I would be happy to help with testing. The 16MB SPI chip have even more space the general configuration at for example a Thinkpad x230 that have just 12MB space.

[tlaurion]

@fhvyhjriur 1% of the population will have 16mb.

Still no TPM.

What is your use case?

[irelativism]

@tlaurion we have TBM, (attention TBM!=TPM)
and you dont need to use blobs like the ME stuff there has been also work on EC on those models so there are several benefits and a lot of usecases.

https://media.ccc.de/v/SHA2017-280-tbm_trusted_boot_module
https://src.whiteboxsystems.nl/TBM
https://nlnet.nl/project/trustedbootmodule/

Cheers Irelativism

[tlaurion]

@tlaurion we have TBM, (attention TBM!=TPM) and you dont need to use blobs like the ME stuff there has been also work on EC on those models so there are several benefits and a lot of usecases.

https://media.ccc.de/v/SHA2017-280-tbm_trusted_boot_module https://src.whiteboxsystems.nl/TBM https://nlnet.nl/project/trustedbootmodule/

Cheers Irelativism

---

previously

@fhvyhjriur :

With the first post i asked for board addition to have heads-maximized as a modern Libreboot replacement with the microcode-updates and all the coreboot updates from the last years included

retroboot fits better the bill asked here. Heads slightly more secure features are TPM based, enforcing early measured boot. Without a TPM, Heads project is diverging from its goal. In the past, KGPE-D16 was added since TPM slot was there, where TPM support was not and where support was finally added recently in Heads tree with coreboot version bump.
I am not clear about #836 meeting the requirement of Heads as of now (USB Security dongle TPM equivalent requires USB being brought prior of measurements, where HID (keyboard) support can theoretically be used to have a rubber ducky (keyboard + flash memory) to sed (find, replace) text in code, or even copy over Heads files by automated HID keyboard input.
The absence of a Disk Unlock Key released by TPM with it's protection offered by Heads' TPM changing its PCRs when Heads goes into Recovery shell and back into GUI... Heads could be mislead to have replaced flashrom, sha256sum... Heads could lie about its attestation results...) You are more then welcome participating in the discussion over there.

this would be done through miniPCIexpress, but is open so offcourse other connections can happend. So there isnt such problem with USB Im working on something I call LIBREBOOK a macbok 2.1 board in a aluminium 8.1 chassis, with recented added amd free graphics (5000), all freesoftware and would definitely like to add a TBM so I dont need to use GRUB2 attestation but use kexec.

@irelativism

https://media.ccc.de/v/SHA2017-280-tbm_trusted_boot_module

Interesting. Fastforwarded video in absence of bundled paper, and was not able to quickly find the schematics and where the TBM would be plugged on the motherboard, and was not able to see if that could work for xxx0 boards.

If you can point at a t=xxx in the video, or more specific documents here or in an additional issue, that might be of interest for the Head's community (As usable Open TPM (other issue) and other projects with guidance on usability, so that not everyone has to read everything to come to a conclusion: Share your thoughts and insights).

---

now

@irelativism : please be move specific!

I have read https://src.whiteboxsystems.nl/TBM/tbm-docs/src/branch/master/kexec.rst and some other docs.
https://src.whiteboxsystems.nl/TBM/tbm-docs/src/branch/master/flashrom.rst was fascinating.

It would be aweomse if whitebox/TBM team reached out to Heads to do a PoC, and/or provide hardware for mpci, but this is not the case.

So what i'm reading across the lines here is that you expect TBM to be integrated inside of Heads for gm45/mac. What I would expect is some PoC code to be in a PR to have something that builds and integrate inside of Heads.

What is missing here, for xxx0 support (technical but real):

• real expectations from users: as of today, 8mb of SPI flash is really limited. Saying that some will unsolder/solder 16mb spi chips is interesting, but from my experience really limited in useable scope. As a fact, not all xxx0 have 8mb of SPI chip space, only vPro models, because ME+AMT was there (a vPro feature giving us minimal needing space)
• Development is struggling with ash/dash from busybox and the need of array is pushing us to ditch ash/dash and include bash inside of the ROMs. This is another 200kb needed, where basic footprint of Heads is already around 8mb today. So adding other flash regions like TBM expects (boot in ro environement) doesn't seem really realisitc there.
• dasharo flashrom (WiP: Switch master flashrom to dasharo/flashrom #1251) includes WP bits. But here again, who will solder WP to GND on their motherboard to write protect their SPI WP regions? This doesn't fit current Heads mindset where ROM is RW and where early TPM measurements provide attestation. Use the Librem Key as a TPM work-alike in the absence of a TPM #493 is another attempt, but requires USB init, so no early verification of firmware, so not sufficient compared to TBM.

The goal of Heads is to provide out of the box, flashable rom images/build recipes to provide "slightly more secure" bios pre-boot environements. Qubes is pushing for D-RTM (t440p, haswell+ possible) taking advantage of TPM and ACM blobs to establish RoT in CPU.

As current state of things, I do not know:

• How easy x200 vPro are still easy to get on second hand market.
• People want more powerful stuff than xx30.
• People want TPM2 and Heads support on newer coreboot supported computers
• The amount of work that would be needed to produce TBM and test this inside of Heads for xxx0

---

@irelativism : Are you are in position to provide PoC code for TBM support inside of Heads and already having mpci TBM ready to test such integration?

[tlaurion]

@fhvyhjriur : what is the current state of xxx0 testing under Heads? Can you refresh my memory on this low priority community task (bringing x200 t400 t500 r400 r500 w500 boards) here? Who will maintain/test them upstream? You would be willing and held accountable if others flash and brick their boards?

I think the x200 is stil lthe most used gm45 laptop. I could try again to bring a board config that would work here. But I cannot add this on my tests and blockers prior of pushing to newer coreboot versions. For information, there are bugs under 4.19 for x200 not resuming from suspend last time I checked. I am not sure how to approach this.

[irelativism]

Thanks for your repply @tlaurion on all the specific points.

My concerns here is solely and only so that users can have a "slightly more secure" bios pre-boot environements. For you to have privacy, security is a must, and for security to be a given, you need user freedom and all libre software. Adding all this blobs only will be detremental to this project in my view, privacy<security<freedom. So until openISA stuff is available we need to relly on preME (2008intel, circa 2013/2014amd) stuff. Sadly most of those boards that are also supported in coreboot dont have integrated TPM on them. So TBM or other kinds of external boards are really the only valid solution and sole way foward really.

Has for assumptions, disclaimer all "leahboot" projects are not to be trusted and at this moment I consider them a possible honeypot personally. the current lead of those projects was homeless, and all of the sudden forcely took over in a very manipulative and devious way of libreboot project, stealing the build system that was been worked on and in the process of releasing and republishing it has if it was that peers work. So neither retroboot, osboot, or libreboot are a valid target for this use cases. If you want to read more on it check https://forums.hyperbola.info/viewtopic.php?pid=4161#p4161

Has for your last question, it depends if the direction of heads is the same has the one I just describe above sure, if not we, probably might just look into developing our own thing based on hyperbk when is realised under beta based openbsd octl instead (kexec equivalent btw). Im just sharing the direction of what I see has alternatives and what probably the heads project should do to selfsustain it, and probably start selling modified hardware in a paralele endeavour, to make this vision a reality ;).

If this is not a vision the communitty is willing to take upon, probably yeah not interested in wasting time in such effort.

P.S. For those that havent listen to talk TBM currently TrustedBootModule uses pioneer board for current implementation, same board used by freedombox sold hardware.

Has allways Cheers.

[tlaurion]

Sadly most of those boards that are also supported in coreboot dont have integrated TPM on them. So TBM or other kinds of external boards are really the only valid solution and sole way foward really.

Well, there was fTPM per ME+AMT, but the goal here is to get rid of it completely.

Alternatives, like said previously, would be to have either:

• bootblock CPU based measurements (BOM enhancements under coreboot) without TPM
• bootblock region write protected and WP pinned down to GND (see WiP: Switch master flashrom to dasharo/flashrom #1251. But would need casual external reflashing when bootblock changes in newer coreboot versions, being problematic for internal upgrades)

@irelativism I now make links with conversations that happened off channel. Hear me out, I see pertinence of bsd based kexec to bsd. I see pertinence on TBM and general open source TPM (see https://nlnet.nl/project/lpnTPM/ as well). But the problem with all of those is to have this happen as early as possible in the firmware boot path. And reading onto TBM didn't satisfy me completely as of now, since I'm not sold to the project (as you might be and that is ok, I understand your goals and they are legitimate) as opposed to what coreboot does, having interfacing as early as in bootblock to use an external device for measurements. Not saying that TBM could not do it, just saying that as of now, my interest into BSD replacement of linux for Heads, TBM integration (or UltraBlue or XYZ) is not a priority for me now, the priority is lowering the bar so that more contributors contribute and more users can use Heads for their own threat model and use cases.

What is missing under Heads today is authentication to go to recovery shell and preventing booting random things (USB boot) to destroy (DoS) the system and prevent internal firmware upgrades without authentication. This is easily achievable through GPG detach signing as authentication mechanism, but going there requires easy keygen/backup/restore/interim usage of backup keypair. Once that is in, having Heads in authenticated way will prevent internal attacks and even using Heads as a recovery shell from non-owners of the machine.

Then blink comparison app + nail polish of screws permits to have pretty good physical access prevention/inspection mechanisms to see if laptop has been tampered with.

Know that at any moment, you could be reflashing internally the whole SPI chip prior of booting. Without TPM, there is no secret storage, so you would still have to trust the OS prompting you for your decryption passphrase.

---

I would be really interested seeing TBM integrated with coreboot, and then having Heads use TBM and integrate toolstack inside of Heads in linux. I understand interest of getting away of linux because bloated, but yet again, it is possible to configure the kernel to only use what is needed, and Heads being a controlled boot policy (script), there isn't much possible there without getting to recovery shell/physical tampering, even less without USB HID in kernel (no USB keyboard here, no rubber ducky, right?) where usb support is limited to controllers and storage and nothing fancy is built-in the kernel.

But again, I understand the interest of going BSD. But what seems to be Heads community is mainly Qubes OS users, relaying on Heads to provide what is possible to have in pre-boot security on a per chosen-blob/platform/threat model/security mechanism. And with D-RTM (I know, more blobs: ACM and SINIT blobs aimed to enable dynamic root of trust and re-measure whenever needed, otherwise what is trusted upon resume from suspend is pretty faith-based).

For older hardware, I am out of ideas now outside of external collaboration. What I pushed for (getting grant, pushing others for grant money, testing other people stuff, integrating, dealing with space constraints consequences) is flashrom and WP. Outside of that, I hope people interested into protecting groups will have the means to push in some direction, not trying to change everything at once.

If you can have TBM people reach out to Heads, that would be great to discuss implementation details under a separate issue.

As of "tomorrow", xxx0 boards could be added back to Heads. My favorite path would be to have people interested into making this happen also contribute (#1282 being the most recent example). Which then I have less problem maintaining a platoform over time, knowing that platforms have at least knowledgable testers, not just users. A reminder that I do not own all the platforms supported. And seeing how long #1234 is taking to have owner's feedback prior of merging changes tells the complexity of maintaining Heads without testers for "supported" configurations. If I do not own a TBM, if I do not own a T400 nor a mac, and I am not a BSD user, I'm not sure how "supported" would be those configurations unless a strong collaboration starts between those projects.

[tlaurion]

@fhvyhjriur @irelativism tried another take to bring t400-maximized, t400-maximized-debug and x200-maximized under #953 (comment)

PR is building and should produce ROMS under CircleCI boards artifacts in less then 1h if I didn't do something stupid.
Please review commit there. And please adapt and propose another PR if that one doesn't work for you.

[tlaurion]

@fhvyhjriur @irelativism flashed produced CircleCI rom on my x200 (vPro:8mb SPI chip) at #953 (comment).

Success. Your turn people: test with t400 and duplicate for boards you are intending to test on each coreboot version bump for the future of Heads (and those platforms intended to be supported with sometimes bug reports to coreboot).

[irelativism]

thanks @tlaurion I dont have t400 but just ordered one so in the next few weeks ounce i receive it will be happy to test it, Also will try to make a few modifications to see if this is something that could work on macbook2.1 and T60 meanwhile, btw hardware I already have in my posetion.
Cheers as allways Irelativism

[tlaurion]

@irelativism hope you ordered a t400 with vpro sticker on. The other x200 that was non vpro was 4mb spi flash and this is unfortunately not really feasible to accomplish without removing modules binaries and libraries that makes Heads to be able to have menus, cryptsetup, lvm, gpg toolstack and other tools, while removing one or some of those would break things.

How much spi space has a macbook2.1?
I guess the same 4mb if not less is the case for t60.

[fhvyhjriur]

I would like to leave a reminder here, that there is still interest. Are there any news about this issue? I wait since the year 2020.

[tlaurion]

@fhvyhjriur @irelativism flashed produced CircleCI rom on my x200 (vPro:8mb SPI chip) at #953 (comment).

Success. Your turn people: test with t400 and duplicate for boards you are intending to test on each coreboot version bump for the future of Heads (and those platforms intended to be supported with sometimes bug reports to coreboot).

@fhvyhjriur @irelativism A reminder that all previous discussions points are still valid and when comes time to testing, ROMs previously produced were not tested. Heads is a community driven project requiring testing, code or sponsoring monetary contributions.

Meanwhile, x230/t430-legacy went deprecated because untested and became UNMAINTAINED in the board tree. Because not tested by board owners in time.

This ticket drifted to other use case but roms never were tested in time when needed, last time a year ago.

I'm thinking of closing this issue as "not planned* because 8mb is too limited and I'm not convinced 16mb would be soldered by a lot.

[fhvyhjriur]

I seem to have missed the links more then a year ago to the testing builds. I am sorry for that. Of course i am willing to do testing like i did before (the files from a year ago are not available any more).
I could do the testing now if you like, but if you say that the time today is better spend on x20 and x30 devices, then i could donate those x00 to other (regular, no heads support asking) users and get my hands on x20 and x30 that are supported by coreboot but currently missing in heads.
For example I have a Thinkpad T420s here and its supported by coreboot https://github.com/coreboot/coreboot/tree/main/src/mainboard/lenovo/t420s
Of course i would also upgrade t420s's SPI to 16 at first like i always do. But if you say, that you would like to not spend time on devices that got OEM produced with something less then 12, then i would also get rid of my x20 series devices and get for example a T530 that seem to need testing with current builds (you moved it to untested).

I close the issue here now.
For people who read this issue sometime later: from the security point of view the x00 series have the problem with missing microcode updates for known security issues. Be aware when using those devices with java script enabled.