Messages in this thread | | | Date | Tue, 1 Aug 2023 13:51:49 -0500 | Subject | Re: [PATCH 1/1] tpm: disable hwrng for fTPM on some AMD designs | From | Mario Limonciello <> |
| |
On 8/1/2023 13:42, 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.
This sounds fine by me too, thanks.
> > 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? > > 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 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
| |