On Fri, Aug 16, 2019 at 05:56:12PM +0200, Alexander Steffen wrote: > > Andrey talked to me a little about this today. Andrey would prefer we > > don't just let the TPM go into a wonky state if it's used during > > suspend/resume so that it can stay resilient to errors. Sounds OK to me, > > but my point still stands that we need to fix the callers. > > > > I'll resurrect the IS_SUSPENDED flag and make it set generically by the > > tpm_pm_suspend() and tpm_pm_resume() functions and then spit out a big > > WARN_ON() and return an error value like -EAGAIN if the TPM functions > > are called when the TPM is suspended. I hope we don't hit the warning > > message, but if we do then at least we can track it down rather quickly > > and figure out how to fix the caller instead of just silently returning > > -EAGAIN and hoping for that to be visible to the user. > > There is another use case I see for this functionality: There are ways for > user space to upgrade the TPM's firmware via /dev/tpm0 (using e.g. > TPM2_FieldUpgradeStart/TPM2_FieldUpgradeData). While upgrading, the normal > TPM functionality might not be available (commands return TPM_RC_UPGRADE or > other error codes). Even after the upgrade is finished, the TPM might > continue to refuse command execution (e.g. with TPM_RC_REBOOT). > > I'm not sure whether all in-kernel users are prepared to deal correctly with > those error codes. But even if they are, it might be better to block them > from sending commands in the first place, to not interfere with the upgrade > process. > > What would you think about a way for a user space upgrade tool to also set > this flag, to make the TPM unavailable for everything but the upgrade > process? > > Alexander NOTE: Just commenting the FW use case. I don't like it because it contains variable amount of reserved time for a hardware resource. Right now a user thread gets a lease of one TPM command for /dev/tpm0 and that is how I would like to keep it. /Jarkko
