On Tue Aug 1, 2023 at 9:42 PM EEST, Linus Torvalds wrote:
On Tue, 1 Aug 2023 at 11:28, Jarkko Sakkinen jarkko@kernel.org wrote:
I would disable it inside tpm_crb driver, which is the driver used for fTPM's: they are identified by MSFT0101 ACPI identifier.
I think the right scope is still AMD because we don't have such regressions with Intel fTPM.
I'm ok with that.
I.e. I would move the helper I created inside tpm_crb driver, and a new flag, let's say "TPM_CHIP_FLAG_HWRNG_DISABLED", which tpm_crb sets before calling tpm_chip_register().
Finally, tpm_add_hwrng() needs the following invariant:
if (chip->flags & TPM_CHIP_FLAG_HWRNG_DISABLED) return 0;How does this sound? I can refine this quickly from my first trial.
Sounds fine.
Mario, it would be good if you could send a fix candidate but take my suggestion for a new TPM chip flag into account, while doing it. Please send it as a separate patch, not attachment to this thread.
I can test and ack it, if it looks reasonable.
My only worry comes from my ignorance: do these fTPM devices *always* end up being enumerated through CRB, or do they potentially look "normal enough" that you can actually end up using them even without having that CRB driver loaded?
I know that QEMU has TPM passthrough but I don't know how it behaves exactly.
Put another way: is the CRB driver the _only_ way they are visible, or could some people hit on this through the TPM TIS interface if they have CRB disabled?
I'm not aware of such implementations.
I see, for example, that qemu ends up emulating the TIS layer, and it might end up forwarding the TPM requests to something that is natively CRB?
But again: I don't know enough about CRB vs TIS, so the above may be a stupid question.
Linus
I would focus exactly what is known not to work and disable exactly that.
If someone still wants to enable TPM on such hardware, we can later on add a kernel command-line flag to enforce hwrng. This ofc based on user feedback, not something I would add right now.
BR, Jarkko