-
-
Notifications
You must be signed in to change notification settings - Fork 185
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inconsistent TOTP/HOTP unseal on T420 (affects other xx20 boards owners?) #1004
Comments
FYI my internal clock does not seem to have been bugging |
@akfhasodh : QubesOS dom0 upgrade affects /boot component in most cases, where QubesOS might also update only binaries and libraries which are not linked to /boot. For Heads considerations, only /boot components (Xen, kernel, initrd and grub file) are considered upon detached signed digest validation, that is, to verify that on the fly generation of sha256sum of /boot content matches what was detached signed with the use of a USB Security dongle GPG functions, resulting into /boot/kexec.sig file. If the generated sha256sum digest doesn't match detached signed result under /boot/kexec.sig, then Heads will show the differences between the digest copy under /boot/kexec_hashes.txt for files that have been deleted or modified, not added. Heads is interested in protecting grub config file changes (options being different at boot time), and known good configuration. Now, to address your question on TOTP/HOTP missing, those are two different things.
Now from the words you used in OP, you seem to be talking about HOTP warning saying to you to plug in the USB dongle. You should never have to regenerate HOTP/TOTP whoich you seem to have done, which flushes the past measurements. If no firmware changes have occured, you should have the same TPMTOTP secret being generated inside of a Qr code. IF you still have the old one plus this new one (each OTP app are different here, some will refuse to add a name that is the same as something already existing) you should have the same TOTP code generated for the same timestamp. Basically, please clarify what you mean by a "missing TOTP/HOTP code thingy popped up". Tampering of the firmware would be impossible AFAIK from dom0, unless In short:
Reflashing the same maximized firmware, asking Heads to keep settings (public key and config changes overlay (/etc/config.user if any) should result in the same TOTP/HOTP measurements, which should not even raise "unable to unseal TOTP secret". Let me know if you need more clarifications. |
Clarifications: The HOTP and TOTP were both unable to be unsealed. Even after generating new secrets, it seems to be unable to unseal thoes as well. /boot is working I believe. Also, the unseal errors only began happening after I updated the qubes boot checksums. |
@akfhasodh I understand you are using maximized hotp build for t420 from other post. I would
Document errors happening along the way if any. |
@tlaurion Ive carried out those steps and its still happening. But ive found that the totp/hotp secrets dont just go away, after rebooting a few times i can usually get a boot screen in which everything goes correctly. So it seems to be some kind of consistency issue. Maybe tpm is glitching? |
@akfhasodh can you elaborate on this? Can you give a screenshot or exact output next time it happens so we can have a trace of the behavior? TPM is rate limiting access, so maybe the glitch experienced here is somehow related to too many failed interactions, which locks the TPM for a time frame. I experienced that at default boot with TPM Disk Unlock key passphrase a couple of times before. Should probably be documented. |
@akfhasodh and you say that state is transient, and resolves itself after a couple of reboots ? |
@tlaurion no, it used to be like that but now the ratio of good boots to bad boots is overwhelmingly bad. |
This happens here: https://github.com/osresearch/heads/blob/055165d61a3c312e7e03998ea832447452a86d71/initrd/bin/gui-init#L195-L209 Which means totp-unseal was unable to unseal secret, consistently to error. But that doesn't give an explanation on why. This gives more information with the actual reported error being : "Error PCR Mismatch from TPM_Unseal" (#780?). This makes me wonder if something is different from 4.8.1 coreboot code between x230 and t420 (and x220). @akfhasodh Would you willing to do that instead of trying to revive what should become dead soon? We missed x220 and t420. I could revive my old branch on top of master so you can test the t420-hotp-maximized board based on coreboot 4.13? The long goal is to move away all Lenovo boards to 4.13, where I tested the x230 myself for a while now. But it doesn't make sense to move away only certain boards and not others to 4.13. |
@tlaurion Im willing to do that. |
@akfhasodh so the discussion should go to #998 |
There might be a possibility that xx20 images have a problem with CBFS region specified. |
@tlaurion In the past, I have attempted soldering on this motherboard, there is still some left, it was to add wires to easily reflash the bios. Could this be the root of the problem? |
It shouldn't, and wouldn't explain why payload gets different measurements across reboots... Do you guys have similar behavior testing #1015 roms? @akfhasodh here is having inconsistencies with payload measurement with both coreboot 4.8.1 and coreboot 4.13 boards, and my only hypothesis as of now is that defined CONFIG_CBFS_SIZE for t420 and maybe x220 is off? |
I commented on #1015, but for clarity repeating that I'm not seeing this issue on the 4.13 t420-hotp-maximized rom. I've rebooted about a dozen times after flashing so far. |
Installed dom0 updates today and re-signed checksums. TOTP/HOTP still works as usual. |
To be closed when #1015 is merged |
#1015 merged |
Heads has been working well without any flaws for a few days now, up until I decided to update dom0 in qubes. I rebooted after the update, at which everything was fine, reverified the checksums and booted up. Upon the second boot after the update, the error screen for a missing TOTP/HOTP code thingy popped up. I generated a new one but now Im wondering if I was compromised. Any help would be appreciated.
The text was updated successfully, but these errors were encountered: