Re: [regression] Bug 216989 - since 6.1 systems with AMD Ryzen stutter when fTPM is enabled

[Jarkko Sakkinen <jarkko@kernel.org>]

On Tue, Feb 07, 2023 at 11:31:37PM -0300, Jason A. Donenfeld wrote:
> On Tue, Feb 7, 2023 at 11:13 PM Jarkko Sakkinen <jarkko@kernel.org> wrote:
> >
> > On Wed, Feb 08, 2023 at 04:13:16AM +0200, Jarkko Sakkinen wrote:
> > > On Thu, Feb 02, 2023 at 07:57:37AM -0500, James Bottomley wrote:
> > > > On Thu, 2023-02-02 at 11:28 +0100, Linux kernel regression tracking
> > > > (Thorsten Leemhuis) wrote:
> > > > [...]
> > > > > So it's a firmware problem, but apparently one that Linux only
> > > > > triggers since 6.1.
> > > > >
> > > > > Jason, could the hwrng changes have anything to do with this?
> > > > >
> > > > > A bisection really would be helpful, but I guess that is not easy as
> > > > > the problem apparently only shows up after some time...
> > > >
> > > > the problem description says the fTPM causes system stutter when it
> > > > writes to NVRAM.  Since an fTPM is a proprietary implementation, we
> > > > don't know what it does.  The ms TPM implementation definitely doesn't
> > > > trigger NV writes on rng requests, but it is plausible this fTPM does
> > > > ... particularly if they have a time based input to the DRNG.  Even if
> > > > this speculation is true, there's not much we can do about it, since
> > > > it's a firmware bug and AMD should have delivered the BIOS update that
> > > > fixes it.
> > > >
> > > > The way to test this would be to set the config option
> > > >
> > > > CONFIG_HW_RANDOM_TPM=n
> > > >
> > > > and see if the stutter goes away.  I suppose if someone could quantify
> > > > the bad bioses, we could warn, but that's about it.
> > > >
> > > > James
> > > >
> > >
> > > And e.g. I do not have a Ryzen CPU so pretty hard to answer such question.
> >
> > ... about hwrng
> 
> Well, the options here are basically:
> 
> a) Do nothing, and just expect people to update their BIOSes, since an
> update is available.
> b) Do nothing, and expect people with broken BIOSes to `echo blacklist
> tpm >> /etc/modprobesomethingsomething`.
> c) Figure out how to identify the buggy BIOS and disable the TPM's rng
> with a quirk in this case.
> d) Figure out how to dynamically detect TPM rng latency, and warn about it.
> e) Figure out how to dynamically detect TPM rng latency, and disable it.
> 
> I think given that a firmware update *is* available, (a) is fine. And
> the generic workaround remains (b). But if you want to be really nice,
> (c) would be fine too. Somebody with the affected hardware would
> probably have to send in some DMI logs or whatever else. (d) and (e)
> sound possible in theory but I dunno really... seems finicky.
> 
> Jason

For now (a), but if someone with capable hardware can make up something
I'm happy to go that through, if it makes sense.

BR, Jarkko