TPM2 support #893
TPM2 support #893
Conversation
|
@osresearch why not simply make romsize bigger instead of deactivating tools? |
|
@osresearch : please apply the following patch for CI to build safeboot on top of master |
|
At this point it boots under coreboot or OVMF and is able to perform a remote attestation to a remote server using |
|
I'll need to rebase and sign all of the commits when I'm back at a machine with my key. Didn't bring the hardware token with me this week. |
|
|
Ah, |
|
|
@osresearch Unfortunately, most of the boards with faked ifd where Heads coreboot config doesn't take advantage of ME freed space won't be able to integrate cryptsetup 2.3 unless #590, or #703 similar approaches to use me_cleaner's freed space (and included generated gbe, ifd BIOS increased region resulting of ME neutered regions): As a result, merging this would break x230, t430, x220 t420 and other smaller SPI based boards. Any other idea to squeeze additional space? |
|
I need to split this into two separate PRs -- one for the tpm2 support (which also adds openssl), the second for the safeboot board config (which adds bash, cryptsetup2, etc). For the cryptsetup, it might be necessary to add a |
|
I've edited this commit to only have the tpm2 module and ROM size increase in the PR. The safeboot config is now in the WIP #907 |
Signed-off-by: Trammell Hudson <[email protected]>
Signed-off-by: Trammell Hudson <[email protected]>
Signed-off-by: Trammell Hudson <[email protected]>
|
@osresearch : would be awesome if a board config with TPM2 was added in this PR to see host build requirements changes and building working. something like qemu-coreboot-tpm2 would be awesome, with your changes needed to be able to do |
|
hmm, so how much work are we talking to update tpmtotp to use a TPM 2.0, assuming it supports the functions necessary? |
|
Right now I'm using a separate TPM2 HMAC keys are neat in that the key never leaves the TPM - it performs the HMAC inside the hardware, so the TOTP secret can't be easily copied. |
|
@osresearch the qemu-coreboot size was increase in coreboot config, but no change or inclusion of new added modules were added into board configuration file itself. Consequently, CI builds don't test current changes of the PR. |
|
What's the status of this PR? I'm looking to port Heads to some System76 laptops in the (not so distant) future and TPM2 support is a hard requirement before then. Is there any work I could do also to test this PR? |
…boot board being built by CI
|
@osresearch @aesrentai Basically, adding on top of master: As a result, https://app.circleci.com/pipelines/github/tlaurion/heads/730/workflows/6ef83293-142d-4028-8108-6df27e947a93/jobs/1023 failed: |
|
@tlaurion @osresearch tpm-tss has another build dependency, autoconf-archive. I applied those exact patches and recreated the error, and installing autoconf-archive on my debian 10 system fixes that error. I'm working on this right now and I'll post my results if/when I hit an error that isn't a simple dependency issue or the build works. Edit: I've probably hit 20+ build dependency issues, even though this box has all the build dependencies listed on the website. If I have time I may try to dockerize this because this is getting annoying. Edit 2: Now this error looks more significant. Edit 3: Well, the obvious workaround is to do a Edit 4: Two more dependency issues I hit when trying to build the board again a few days later are libjson-c-dev and libcurl (whatever packages provides that). Those either need to be included in the system dependencies or added to the tpm2-tss module file. I also hit another dumb error that I'm trying to solve which is, get this, yep, that's the entire error. I can't even find any logs. Yay. |
|
@aesrentai up to date dependencies on debian-10 are here https://github.com/osresearch/heads/blob/master/.circleci/config.yml#L13 qemu-coreboot can be tested by making the board with qemu-coreboot run. |
|
@aesrentai the vtpm magic that was bound into "qemu-coreboot board run" is here Edit: and was moved into a safeboot board config here from that commit. @osresearch seperated the TPM2 implementation from the board configuration later on in this PR force commits, that you can look into. I think the latest was here to be able to test it. Maybe the cleanest way to test this up from now would be to create a qemu-coreboot-vtpm2 board, associated coreboot config and linux config? |
|
I wasn't aware we had a version of qemu with a working tpm2-- last I remembered even tpm 1 emulation didn't work. I'll take a look, although it may take a bit because this is the first time I've done anything like this so I'll have to figure out how QEMU works. General plan is to do what you said, create a qemu-tpm2 board and see what works and what doesn't. |
TPM1 emulation magic (swtpm) was not build under Heads nor dealt with into the qemu board run statement and was subject of issue tracking #516 #701. It should theoretically work based on this PoC by tweaking swtpm into being into 1.2 mode PR welcome, as usual. |
|
I'm not particularly interested in trying to get TPM 1.2 emulation working (I'm almost tunnel visioned on getting S76 and Star Labs laptop support as a way for Heads to rapidly gain users), but at face value that PR about tweaking swtpm doesn't make sense. From the swtpm man pages: so shouldn't tpm 1.2 emulation just work if you don't pass the Once I get swtpm working I'll be able to move on to actually testing if the tpm2 tools work (which they should). Right now my ultimate problem in getting S76 support is actually acquiring the hardware, which is made more difficult by the fact that I am a broke college student. Edit: One contribution that I may work on far in the future is a more comprehensive test suite for heads. Right now we only test that Heads builds successfully, but that's really the bare minimum. At least we should have a set of commands that can be run manually in qemu that exercises all of Head's features. Ideally this would be automated through CircleCI, although I'm not sure if this is possible (because you have to run qemu and then pass a script to the guest, although an ugly hack to solve the second problem would be somewhere in the init script). |
|
superseded (and included and reworked) under #1292 |
|
Securityfs removed under #1292 not sure I understand the scope from where that was needed but maybe safeboot. To be reinserted later if needed. |
This is very preliminary support for the
tpm2-toolslinked against musl and running in the initrd. This brings in some heavy weight dependencies, like openssl, so it requires a large flash to put into firmware.Temporarily I've disabled a few features in the, although my plan is to use the Heads kernel and initrd as a UEFI or PXE bootloader as part of https://safeboot.dev, which doesn't have the same size restrictions.coreboot-qemuconfig to make it fitI also added code to the qemu
make runtarget that sets up an emulated tpm2 for testing against, which might be a useful example for other targets as well.