Talos II - latest rolling release - TPM discovery and usage unstable #415
Labels
Milestone
Comments
This was referenced May 20, 2023
|
This is testing rom link provided under #416 (comment) After selecting new boot device on fresh flash (nvme part 2, flashing backconfig and soft reboot): If I do poweroff from Heads: And then poweron from local shell: bmc connection died. On clean boot: Normal cbmem -1: Then calling reboot: Doing factory reset after a warm reboot: |
|
Unfortunately, even on a clean boot (poweroff poweron from bmc) state of I2C still unstable. @SergiiDmytruk you obtained different results while reproducing #416 (comment) top lines? |
|
@SergiiDmytruk : Please test "F OEM Factory Reset / Re-Ownership" menu option with a OpenGPG security dongle connected (nitrokey, librem key, gnuk, yubikey etc). Unless you tell me that a bmc initiated poweroff+poweron is not equivalent of a cold boot, we still have three problems here:
|
|
|
@tlaurion, my primary intention with the TPM fix so far was to prevent Fast reboot results in different PCR values, the fix will probably require making Now, I did notice that poweroff/poweron produces different dialogs on different runs, but wasn't sure why. I see that requests time out, but if the operation eventually succeeds that shouldn't matter. Are dialogs always related to TPM state? Isn't |
Redoing from overnight poweroff through
Those are related to how we update the firmware as of now, without a provided "uprade image" that is meant to be flashed within Heads, since CBFS injected keyring and trustdb is not reinjected at internal upgrade (we actually simulate an initial "external flashing" through bmc here, which should only happen once and flashing upgrade images internally after, which would take gpg key and user files from cbfs, export them, and reinject them as is in the next coreboot image into cbfs. Heads currently starts "clean" and only takes into consideration the PCRs that he expects stable from coreboot part. That is originally, PCR2 (and or PCR0-2), but nothing else (Heads expects to play with PCR4-7, and 16. Heads "exits early" when there is:
But.... When doing OEM factory reset, and generating gpg key material, injecting that into the firmware and sealing TOTP, Heads then issues a warm reboot. And then this is what we currently experience: The Qemu TPM1/TPM2 boards include the following debug statements that permit to output TRACE and DEBUG output on the console: I would suggest that we turn that on talos2 board until we get this working so the whole call tree and information on what is sealed/unsealed is understood. The qemu-whiptail-tpm1 board mimics correctly what is happening with the TPM and permits to enter recovery shell on the bmc console and look at those traces under /tmp/debug.log as well. I can turn that on in runtime, which I will with the coreboot+bootblock binaries you asked me to test by doing: Select Save the current configuration to the running BIOS That initiates a warm reboot, once again. But now, we see what happens from Heads perspective: Let's redo it, and reboot from the command line: So. On second warm reboot: quick notes:
Note that I already generated gpg key material and already injected it into cbfs on first boot prompt. So measurements of it is done by heads through cbfs-init script early in init calls. If I reseal measurements on actual boot: To my eyes, the sealing operation is simply not working at all from I2C errors. And therefore, the unsealing is not working either since timeouts? |
|
@SergiiDmytruk Also we seem to hit a corner case doing warm reboot, hitting internal counter which after 3 refuses to boot and requiring a coldboot? With my testrun here, I could not use BMC to poweroff and on (disconnecting machine from power to flush bmc memory and start fresh here). Those are the contradicting lines for that matter: Warm reboot increases a counter going back down the chain and then up: |
Continuing to main menu to at least reset tpm (Boot device not configured here) Please try and see if you get different results. On my side, even on a cold boot, nothing gets sealed. |
|
Thanks for the explanation. I guess resetting PCRs might not work (at least not for all of them) and we might want to just disable fast reboot and always do a full reboot. Will also try to reproduce sealing/unsealing issue and see what happens in the driver.
That reboot counter is merely informational. Boot count is a completely separate entity. In my tests, |
|
Looks like TPM might not be at fault. # pcr 4 is expected to be zero (boot mode: init)
dd if=/dev/zero bs="$(tpmr pcrsize)" count=1 status=none >> "$pcrf"While this isn't the case due to: I remember extending separators into PCR being discussed before, but they weren't taken into account by the code. I've disabled fast reboot and PCR separators in linuxboot/heads#1411, but it needs testing, I just modified
|
|
https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClient_PFP_r1p05_v23_pub.pdf shows in table 1 what should be measured to which PCR. Heads depends on coreboot not being compliant with this specification so I'd say that this script should be modified. I2C errors is another beast altogether... |
I don't get the conclusion. If Heads doesn't care about specification why try to follow it? If we do follow it in |
|
One second. Goal is not to drift into noncompliance. The goal from heads is to extend pcr4 to break measurements consistency and prevent unsealing of secrets when one went to recovery. Will come back here give me a little time to test things Edit: One one shell I nitiated poweroff while expecting BMC to still be responsive. |
|
@SergiiDmytruk comment on PCR10 still applies at linuxboot/heads#1411 (comment) though |
|
@SergiiDmytruk Sorry. Discussed off channel. Problems with coreboot-git target not being rebuilt. Separate issue. |
I understand this is off-topic. Sorry for my $0.02. I want to ensure we are on the same page. Any commercial offering in Dasharo (coreboot+Heads) should be as compliant as reasonable. We can be non-compliant only when we have strong evidence that non-compliance gives bigger value to project supporters who vote with resources that keep the open-source ecosystem running. Non-compliance with TCG may lead to higher costs of maintenance and integration of value-added features (e.g., TrenchBoot integration). No matter what we think about certification and compliance programs, those are among the strongest incentives for procurement departments. |
I applied fix so that pcr4 and pcr10 ate taken into consideration. linuxboot/heads@master...tlaurion:heads:Dasharo_fix-tpm_staging @SergiiDmytruk please cherry-pick what is needed. |
|
@tlaurion Updated PR which should now build Also, PCR10 is updated by Linux, not skiboot, and another way of addressing it is removing/changing: in |
@SergiiDmytruk |
|
Yes, not exactly obvious, but its a separate pseudo file-system that needs to be mounted there: |
|
Doesn't seem to be really useful under Heads situation. linuxboot/heads@6a9e7e2#commitcomment-115172968 insmoding is a wrapper around busybox under heads and extends PCR5. @SergiiDmytruk Additional thoughts? Otherwise I think there is no reason to re-add securityfs as of now nor consider pcr10 in the sealing/unsealing operations. |
tlaurion
referenced
this issue
in linuxboot/heads
May 26, 2023
This is unused, remove it. Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
|
I think not enabling IMA is what I'd do, it's enabled only because Raptor's kernel config had it. |
Weird considering no TPM ever worked on Talos II |
The issue with I2C was due to With all the other patches in place, OTP code seems to be fine and continues to work after a reboot. |
|
@SergiiDmytruk stable and without errors on my side! Please use master's .circleci config file and force push and this will be ready for merge. |
@tlaurion never worked or never been tried? Can you give the source of that information? |
@krystian-hebel This is from memory. I would have to dig in the research that was done prior of sticking to the production of the tpm 1.2 module and/or discussions that happened with Timothy on the TPM connector, CPU cycles that were not compliant. 3mdeb might actually have better traces then I do on that matter. I thought it was a known fact that the Talos II board never really had a TPM tested working because it was poorly implemented. It is to remind readers that RaptorEngineering/RaptorSystems are not fond of TPM closed source technologies, which might explain why not much testing was put into TPM support even if OpenPower developped components were supporting them. Another question would be how difficult would it be to have a TPM2 module variant since Heads evolved since the original scope of Talos II, and could work with those as well if supply chain is easier for TPM2 vs TPM1.2, and that Heads TPM2 implementation enforces encryption with chip for all communications with it, preventing other possible classes of attacks. |
From the perspective of the coreboot port to Talos II, this is pure scope creep, which should be addressed in a different place. We can easily chase Heads for the next three years for what we need more resources. A better decision is to understand what issues we have, which are our initial scope, gather those, evaluate, and find funding. Talos II is not only a POWER9 platform supported by skibook. We can easily imagine IBM hardware that uses TPMs in production—especially knowing their extensive engagement in TPM and IMA in Linux. |
Totally agree. My point was simply to document here what made us decide to create a TPM module since Talos II mainboard could not use available ones. |
I thought it was about that, but it seems there was a misunderstanding. We never said that TPM wasn't supported on Talos II, the only thing we established is that it is impossible to use LPC TPMs due to TPM LPC cycles being (AFAICT) impossible to generate by SoC. |
|
This issue does not adhere to the standards and was not created using any of the available templates: https://github.com/Dasharo/dasharo-issues/issues/new/choose It also touches multiple topics, and most of them seems resolved already. @krystian-hebel will summarize the actual state and describe the expected behavior in heads, which is not there yet (the last missing piece). After PR implementing this is linked here and merged, we will proceed with closing this issue. If there are any more requests to this platform, please create new tickets and clearly describe what the expected / actual behavior was. |
|
@macpijan indeed. This issue was opened when TPM was not discovered correctly at boot. Was updated numerous times since then. Issuing cold reboot instead of fast reset was also needed to have TPM have the same measurements on reset to unseal TOTP. We are at that point. The next issue still unresolved now is to modify kexec-seal-key and kexec-unseal-key and qubes-measure-luks scripts so that measurements are reflecting a clean boot state. Problem is that on x86 platforms, it was possible to take for granted that some PCRs would be zeroed at boot. This cannot be the case now, since separators are extending pcr 4-7. It was discussed under heads issue that the way forward would be to replay TCPA log to have expected boot values at time of sealing the disk unlock key, which is the current missing piece to finish Heads TPM support. The extended measurements in PCRs should be used as is to do the unseal operation and the new code should cause no regression on x86 boards. That is, replaying tcpa log on both architectures should reproduce expected state at sealing and unsealing, which should unseal the TPM sealed disk unlock key when provided with the expected passphrase at unseal operation. The unseal operation is expected to fail if the PCRs unmatch, which should only happen if the user went to recovery shell, which extends PCR4, or loaded USB storage drivers etc from other operations done in the boot path. But booting directly to default boot option, typing the TPM nv region disk unlock password should unseal the disk unlock key, construct secret cpio which is then passed to kexec call for the OS to use it. TLDR: as of today, PCRs are unexpectedly extended on ppc64 bootpath as opposed to x86. Heads seal/unseal key operations should be unified to work for both architectures without causing regression for x86. |
|
This issue is being continued in issue #475, so I am closing it as a duplicate. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
linuxboot/heads#1313 (comment)
The text was updated successfully, but these errors were encountered: