From: "Jarkko Sakkinen" <jarkko@kernel.org>
To: "Mario Limonciello" <mario.limonciello@amd.com>,
"Jason A. Donenfeld" <Jason@zx2c4.com>,
"Linus Torvalds" <torvalds@linux-foundation.org>
Cc: <linux@dominikbrodowski.net>,
"Daniil Stas" <daniil.stas@posteo.net>,
<James.Bottomley@hansenpartnership.com>,
<linux-integrity@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<regressions@leemhuis.info>, <stable@vger.kernel.org>
Subject: Re: [PATCH 1/1] tpm: disable hwrng for fTPM on some AMD designs
Date: Tue, 01 Aug 2023 21:52:23 +0300 [thread overview]
Message-ID: <CUHFOCLWR4VO.OLBGKIXELSIN@suppilovahvero> (raw)
In-Reply-To: <61b363bc-286a-535c-27da-0f52673768ad@amd.com>
On Tue Aug 1, 2023 at 6:04 AM EEST, Mario Limonciello wrote:
> On 7/31/23 18:40, Jason A. Donenfeld wrote:
> > Hi all,
> >
> > I've been tracking this issue with Mario on various threads and
> > bugzilla for a while now. My suggestion over at bugzilla was to just
> > disable all current AMD fTPMs by bumping the check for a major version
> > number, so that the hardware people can reenable it i it's ever fixed,
> > but only if this is something that the hardware people would actually
> > respect. As I understand it, Mario was going to check into it and see.
> > Failing that, yea, just disabling hwrng on fTPM seems like a fine
> > enough thing to do.
> >
> > The reason I'm not too concerned about that is twofold:
> > - Systems with fTPM all have RDRAND anyway, so there's no entropy problem.
> > - fTPM *probably* uses the same random source as RDRAND -- the
> > TRNG_OUT MMIO register -- so it's not really doing much more than what
> > we already have available.
>
> Yeah I have conversations ongoing about this topic, but also I concluded
> your suspicion is correct. They both get their values from the
> integrated CCP HW IP.
>
> >
> > So this all seems fine. And Jarkko's patch seems more or less the
> > straight forward way of disabling it. But with that said, in order of
> > priority, maybe we should first try these:
> >
> > 1) Adjust the version check to a major-place fTPM version that AMD's
> > hardware team pinky swears will have this bug fixed. (Though, I can
> > already imagine somebody on the list shouting, "we don't trust
> > hardware teams to do anything with unreleased stuff!", which could be
> > valid.)
>
> I find it very likely the actual root cause is similar to what Linus
> suggested. If that's the case I don't think the bug can be fixed
> by just an fTPM fix but would rather require a BIOS fix.
>
> This to me strengthens the argument to either not register fTPM as RNG
> in the first place or just use TPM for boot time entropy.
>
> > 2) Remove the version check, but add some other query to detect AMD
> > fTPM vs realTPM, and ban fTPM.
>
> AMD doesn't make dTPMs, only fTPMs. It's tempting to try to use
> TPM2_PT_VENDOR_TPM_TYPE, but this actually is a vendor specific value.
>
> I don't see a reliable way in the spec to do this.
>
> > - Remove the version check, and just check for AMD; this is Jarrko's patch.
>
> I have a counter-proposal to Jarkko's patch attached. This has two
> notable changes:
>
> 1) It only disables RNG generation in the case of having RDRAND or RDSEED.
> 2) It also matches Intel PTT.
>
> I still do also think Linus' idea of TPMs only providing boot time
> entropy is worth weighing out.
You should add something like TPM_CHIP_HWRNG_DISABLED instead and
set this in tpm_crb before calling tpm_chip_register().
Nothing else concerning AMD hardware should be done in tpm-chip.c.
It should only check TPM_CHIP_HWRNG_DISABLED in the beginning of
tpm_add_hwrng().
BR, Jarkko
next prev parent reply other threads:[~2023-08-01 18:52 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-14 20:19 [PATCH 0/1] Avoid triggering an fTPM bug from kernel Mario Limonciello
2023-02-14 20:19 ` [PATCH 1/1] tpm: disable hwrng for fTPM on some AMD designs Mario Limonciello
2023-02-17 15:18 ` Thorsten Leemhuis
2023-02-17 22:35 ` Jarkko Sakkinen
2023-02-18 2:25 ` Limonciello, Mario
2023-02-21 22:53 ` Jarkko Sakkinen
2023-02-21 23:10 ` Limonciello, Mario
2023-02-27 10:57 ` Thorsten Leemhuis
2023-02-27 11:14 ` Jarkko Sakkinen
2023-02-27 11:16 ` Jarkko Sakkinen
2023-02-17 22:05 ` Jarkko Sakkinen
2023-07-27 15:38 ` Daniil Stas
2023-07-27 15:42 ` Mario Limonciello
2023-07-27 16:39 ` Daniil Stas
2023-07-27 16:41 ` Mario Limonciello
2023-07-27 16:50 ` Daniil Stas
2023-07-27 16:51 ` Mario Limonciello
2023-07-27 17:05 ` Daniil Stas
2023-07-28 20:41 ` Linus Torvalds
2023-07-28 21:01 ` Limonciello, Mario
2023-07-28 21:38 ` Linus Torvalds
2023-07-28 21:47 ` Limonciello, Mario
[not found] ` <CUGAV1Y993FB.1O2Q691015Z2C@seitikki>
2023-07-31 19:05 ` Linus Torvalds
2023-07-31 19:18 ` Limonciello, Mario
2023-07-31 19:30 ` Linus Torvalds
2023-07-31 21:57 ` Limonciello, Mario
2023-07-31 23:28 ` Linus Torvalds
2023-07-31 23:40 ` Jason A. Donenfeld
2023-08-01 3:04 ` Mario Limonciello
2023-08-01 11:36 ` Mateusz Schyboll
2023-08-01 18:52 ` Jarkko Sakkinen [this message]
2023-08-01 18:55 ` Jarkko Sakkinen
2023-08-01 18:28 ` Jarkko Sakkinen
2023-08-01 18:42 ` Linus Torvalds
2023-08-01 18:51 ` Mario Limonciello
2023-08-01 19:09 ` Jarkko Sakkinen
2023-08-02 23:13 ` Jerry Snitselaar
2023-08-03 0:34 ` Stefan Berger
2023-07-31 21:44 ` Limonciello, Mario
2023-07-28 19:30 ` Jarkko Sakkinen
2023-07-28 20:18 ` Daniil Stas
2023-07-31 10:14 ` Jarkko Sakkinen
2023-07-31 10:28 ` Daniil Stas
2023-07-31 11:07 ` Jarkko Sakkinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CUHFOCLWR4VO.OLBGKIXELSIN@suppilovahvero \
--to=jarkko@kernel.org \
--cc=James.Bottomley@hansenpartnership.com \
--cc=Jason@zx2c4.com \
--cc=daniil.stas@posteo.net \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@dominikbrodowski.net \
--cc=mario.limonciello@amd.com \
--cc=regressions@leemhuis.info \
--cc=stable@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.