[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <CVAFIDGCEPEC.2R5MSSAO5M8UA@suppilovahvero>
Date: Mon, 04 Sep 2023 23:51:53 +0300
From: "Jarkko Sakkinen" <jarkko@...nel.org>
To: "Jerry Snitselaar" <jsnitsel@...hat.com>
Cc: <linux-integrity@...r.kernel.org>, <stable@...r.kernel.org>,
"Todd Brandt" <todd.e.brandt@...el.com>,
"Peter Huewe" <peterhuewe@....de>,
"Jason Gunthorpe" <jgg@...pe.ca>,
"Mario Limonciello" <mario.limonciello@....com>,
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3] tpm: Enable hwrng only for Pluton on AMD CPUs
On Wed Aug 30, 2023 at 9:25 PM EEST, Jerry Snitselaar wrote:
>
>
> > On Aug 29, 2023, at 12:03 PM, Jerry Snitselaar <jsnitsel@...hat.com> wrote:
> >
> > On Wed, Aug 23, 2023 at 02:15:10AM +0300, Jarkko Sakkinen wrote:
> >> 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@...r.kernel.org
> >> Fixes: 554b841d4703 ("tpm: Disable RNG for all AMD fTPMs")
> >> Reported-by: Todd Brandt <todd.e.brandt@...el.com>
> >> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217804
> >> Signed-off-by: Jarkko Sakkinen <jarkko@...nel.org>
> >> ---
> >> v3:
> >> * Forgot to amend config flags.
> >> v2:
> >> * CONFIG_X86
> >> * Removed "Reviewed-by: Jarkko Sakkinen <jarkko@...nel.org>"
> >> * Removed "Signed-off-by: Mario Limonciello <mario.limonciello@....com>"
> >> ---
> >> drivers/char/tpm/tpm_crb.c | 33 ++++++++-------------------------
> >> 1 file changed, 8 insertions(+), 25 deletions(-)
> >>
> >
> > Reviewed-by: Jerry Snitselaar <jsnitsel@...hat.com>
>
>
> It looks like the Fedora folks are getting more reports of the issue.
https://lore.kernel.org/linux-integrity/20230904202512.29825-1-jarkko@kernel.org/T/#u
I have all the possible reported-by's. I still don't fully understand
kernel bugzilla's role. I don't oppose having it but e.g. for me
reporter has been traditionally someone who reports the bug in LKML, not
in bugzilla. Also the ambiguity of the whole discussion has been over
the top. E.g. why bugzilla even has a field for reporter if that is not
*the* reporter at least according to this discussion?
And in the case of this bug, the reporter in bugzilla was the same exact
person who mailed about it to LKML.
I'm actually cool with almost any policy, as long as there is at least
some policy in existence. Pretty confusing exercise overally, and very
time consuming for a maintainer.
BR, Jarkko
Powered by blists - more mailing lists