On Wed Nov 13, 2024 at 8:12 PM EET, James Bottomley wrote: > > I think we might have to expect the NULL name to change on actual > > hibernation because unlike suspend to ram it does power off the TPM. > > I checked the code: we're coming in on the correct path to renew the > null seed after hibernation, so it should all work. The problem seems > to be that your TPM itself is doing something invalid because the name > we calculate for the primary key doesn't match what your TPM says it > should be. Absent some form of attack or bus integrity problem, that > shouldn't ever happen, so I'm even more curious to know why it worked > in 6.11.5 and before and whether current upstream works. > > I haven't found it yet, but I think the every 10s signature is because > the hibernation path is trying to restart the TPM device and won't take > no for an answer. My fix returned the behavior how it was before my earlier fix in this corner case (i.e. disable TPM). The issue has gone unnoticed before since it has emitted only a single klog entry. On suspend this has not happened to me so obvious deduction is that hibernate resets the null seed. Hibernate needs an addition a fix to disable bus encryption from kernel command-line completely, i.e. tpm.disable_integrity following the convention from my earlier fix [1]. Fast-forward, in order to *enable* bus encryption with hibernate, a feature patch would be needed to specify a NV key in the kernel command-line. It probably cannot be resolved with a null key, at least not based on these empirical results... I would not mind to be wrong in this tho. So to summarize: 1. Fix: tpm.disable_integrity 2. Feature: tpm.integrity_key=<persistent handle> I've never got hibernate working even after trying and without even having TPM in the configuration so pretty hard to test it beforehand... [1] https://lore.kernel.org/linux-integrity/20241113184449.477731-1-jarkko@xxxxxxxxxx/T/#u BR, Jarkko
