heads
heads copied to clipboard
linuxboot
Images for x200, t400, t500, r400, r500, w500
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: https://github.com/osresearch/heads/issues/621#issuecomment-551989960
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: https://github.com/osresearch/heads/issues/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.
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.
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
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.
@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.
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.
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.
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.
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.
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
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
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.
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.
When the TPM is disabled when disabling ME, could some HOTP-maximized heads images be made?
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.
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 https://github.com/osresearch/heads/issues/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.
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.
This would be probably the x200 maybe even this month.
Pull Requests (PR) welcome.
There is already this here: https://github.com/osresearch/heads/commit/7373d5320377a004cff9f0ab1db15265410597b2 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?
@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.
- [ ] x200-maximized -> PR #934, build, direct link to rom
- [ ] t400-maximized - > PR #953
- [ ] t500-maximized
- [ ] r500-maximized
- [ ] w500-maximized
Nice! have you looked into TBM project external TPM like for boot process, there might be some overlap here.
@irelativism @fhvyhjriur added you under #692
@irelativism direct link to TBM?
@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.
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?
@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).
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.
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 https://github.com/osresearch/heads/pull/947 (downloading tarballs from ftpmirror.gnu.org) is a temporary problem needing fixing (upstream or with some creativity) to have successful builds for everyone.
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.