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.