Re: [PATCH v3] tpm: Enable hwrng only for Pluton on AMD CPUs

From: Jarkko Sakkinen
Date: Mon Sep 04 2023 - 18:32:51 EST


On Fri Sep 1, 2023 at 11:49 AM EEST, Thorsten Leemhuis wrote:
> [CCing Linus, as this triggered my "this is moving to slowly" threshold,
> as (a) the initial report was two weeks ago by now (b) a fix seems
> within reach for nearly as long (c) the problem seems to annoy quite a
> few people, as the culprit of this regression made it into 6.5 and was
> picked up for 6.1.y and 6.4.y (rightfully so I'd say, as it fixes an
> earlier regression)]
>
> On 29.08.23 10:38, Linux regression tracking (Thorsten Leemhuis) wrote:
> > On 28.08.23 02:35, Mario Limonciello wrote:
> >> On 8/27/2023 13:12, Jarkko Sakkinen wrote:
> >>> On Wed Aug 23, 2023 at 9:58 PM EEST, Mario Limonciello wrote:
> >>>> On 8/23/2023 12:40, Jarkko Sakkinen wrote:
> >>>>> On Wed Aug 23, 2023 at 11:23 AM EEST, Paul Menzel wrote:
> >>>>>> Am 23.08.23 um 01:15 schrieb Jarkko Sakkinen:
> >>>>>>> The vendor check introduced by commit 554b841d4703 ("tpm: Disable
> >>>>>>> RNG for
> >>>>>>> all AMD fTPMs") doesn't work properly on a number of Intel fTPMs. 
> >>>>>>> On the
> >>>>>>> reported systems the TPM doesn't reply at bootup and returns back the
> >>>>>>> command code. This makes the TPM fail probe.
> >>>>>>>
> >>>>>>> Since only Microsoft Pluton is the only known combination of AMD
> >>>>>>> CPU and
> >>>>>>> fTPM from other vendor, disable hwrng otherwise. In order to make
> >>>>>>> sysadmin
> >>>>>>> aware of this, print also info message to the klog.
> >>>>>>>
> >>>>>>> Cc: stable@xxxxxxxxxxxxxxx
> >>>>>>> Fixes: 554b841d4703 ("tpm: Disable RNG for all AMD fTPMs")
> >>>>>>> Reported-by: Todd Brandt <todd.e.brandt@xxxxxxxxx>
> >>>>>>> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217804
> >>>>>>> Signed-off-by: Jarkko Sakkinen <jarkko@xxxxxxxxxx>
> >>>>>>
> >>>>>> Mario’s patch also had the three reporters below listed:
> >>>>>>
> >>>>>> Reported-by: Patrick Steinhardt <ps@xxxxxx>
> >>>>>> Reported-by: Ronan Pigott <ronan@xxxxxx>
> >>>>>> Reported-by: Raymond Jay Golo <rjgolo@xxxxxxxxx>
> >
> > [...] this seems to become a regression
> > that is annoying quite a few people (in 6.5 and 6.4.y afaics), so it
> > would be good to get the fix merged to mainline rather sooner than
> > later. Are these warnings and the mentioning of affected machines in the
> > patch descriptions the only remaining problems, or is there anything
> > else that needs to be addressed?
>
> Hmmm. Quite a bit progress to fix the issue was made in the first week
> after Todd's report; Jarkko apparently even applied the earlier patch
> from Mario to his master branch:
> https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/commit/?id=b1a62d41bdc1d15b0641759717e8c3651f0a810c
> But since then (aka in the past week) there was not much progress.
>
> Wondering what's up here -- and if both patches are needed or just one
> of them (I suspect it's the latter).
>
> Checked lore and noticed that Jarkko was not much active in kernel land
> during the past few days; happens, *no worries at all*. But still would
> be good if this could be resolved rather sooner that later. Just not
> sure how to achieve that.
>
> Mario, could you maybe pick this up in case Jarkko doesn't show up soon
> soon? From an earlier message in the thread it sounded like all that was
> missing was a slightly improved patch description? Or am I missing
> something?
>
> Ciao, Thorsten (who feels bad that he's putting pressure on people;
> sorry for that, but that duty comes with the "regression tracker" hat)
> --
> Everything you wanna know about Linux kernel regression tracking:
> https://linux-regtracking.leemhuis.info/about/#tldr
> If I did something stupid, please tell me, as explained on that page.
>
> #regzbot poke

Could it be possible to extend the actual kernel documentation
to give at least some guidelines how a maintainer should deal
with the bugzilla?

I do not oppose having it but IMHO at least the basics should
be in the actualy process documentation. You can even put a
link to this URL to that.

I posted a PR today with the hopefully final fix:

https://lore.kernel.org/linux-integrity/20230904202512.29825-1-jarkko@xxxxxxxxxx/T/#u

BR, Jarkko