Re: [PATCH 1/1] tpm: disable hwrng for fTPM on some AMD designs

[Stefan Berger <stefanb@linux.ibm.com>]

On 8/2/23 19:13, Jerry Snitselaar wrote:
> On Tue, Aug 01, 2023 at 10:09:58PM +0300, Jarkko Sakkinen wrote:
>> 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.
>>
> 
> I just created a passthrough tpm device with a guest which it is using
> the tis driver, while the host is using crb (and apparently one of the
> amd devices that has an impacted fTPM). It looks like there is a
> complete separation between the frontend and backends, with the front
> end providing either a tis or crb interface to the guest, and then the
> backend sending commands by writing to the passthrough device that was
> given, such as /dev/tpm0, or an emulator such as swtpm. Stefan can
> probably explain it much better than I.


You explained it well... The passthrough TPM is only good for one VM (if
at all), and all other VMs on the same machine should use a vTPM. Even
one VM sharing the TPM with the host creates a potential mess with the
shared resources of the TPM, such as the state of the PCRs.

When that guest VM using the passthrough device now identifies the underlying
hardware TPM's firmware version it will also take the same action to disable
the TPM as a source for randomness. But then a VM with a passthrough TPM
device should be rather rare...

> 
>>> 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.

CRB and TIS are two distinct MMIO type of interfaces with different registers etc.

AMD could theoretically build a fTPM with a CRB interface and then another one with the same firmware and the TIS, but why would they?

    Stefan


>>
>>> 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
>