linux-kernel - Re: [PATCH v2] tpm: Don't make vendor check required for probe

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 22 Aug 2023 17:56:03 +0300
From:   "Jarkko Sakkinen" <jarkko@...nel.org>
To:     "Mario Limonciello" <mario.limonciello@....com>
Cc:     <linux-integrity@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <stable@...r.kernel.org>, "Todd Brandt" <todd.e.brandt@...el.com>,
        "Patrick Steinhardt" <ps@....im>, "Ronan Pigott" <ronan@....ie>,
        "Raymond Jay Golo" <rjgolo@...il.com>
Subject: Re: [PATCH v2] tpm: Don't make vendor check required for probe

On Tue Aug 22, 2023 at 5:05 PM EEST, Mario Limonciello wrote:
> On 8/22/2023 08:22, Jarkko Sakkinen wrote:
> > On Mon Aug 21, 2023 at 5:02 PM EEST, Mario Limonciello 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.
> >>
> >> As this isn't crucial for anything but AMD fTPM and AMD fTPM works, check
> >> the chip vendor and if it's not AMD don't run the checks.
> >>
> >> Cc: stable@...r.kernel.org
> >> Fixes: 554b841d4703 ("tpm: Disable RNG for all AMD fTPMs")
> >> Reported-by: Todd Brandt <todd.e.brandt@...el.com>
> >> Reported-by: Patrick Steinhardt <ps@....im>
> >> Reported-by: Ronan Pigott <ronan@....ie>
> >> Reported-by: Raymond Jay Golo <rjgolo@...il.com>
> >> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217804
> >> Signed-off-by: Mario Limonciello <mario.limonciello@....com>
> >> ---
> >> v1->v2:
> >>   * Check x86 vendor for AMD
> >> ---
> >>   drivers/char/tpm/tpm_crb.c | 7 ++++++-
> >>   1 file changed, 6 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
> >> index 9eb1a18590123..7faf670201ccc 100644
> >> --- a/drivers/char/tpm/tpm_crb.c
> >> +++ b/drivers/char/tpm/tpm_crb.c
> >> @@ -465,8 +465,12 @@ static bool crb_req_canceled(struct tpm_chip *chip, u8 status)
> >>   
> >>   static int crb_check_flags(struct tpm_chip *chip)
> >>   {
> >> +	int ret = 0;
> >> +#ifdef CONFIG_X86
> >>   	u32 val;
> >> -	int ret;
> >> +
> >> +	if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD)
> >> +		return ret;
> >>   
> >>   	ret = crb_request_locality(chip, 0);
> >>   	if (ret)
> >> @@ -481,6 +485,7 @@ static int crb_check_flags(struct tpm_chip *chip)
> >>   
> >>   release:
> >>   	crb_relinquish_locality(chip, 0);
> >> +#endif
> > 
> > Looks much better but the main question here is that is this combination
> > possible:
> > 
> > 1. AMD CPU
> > 2. Non-AMD fTPM (i.e. manufacturer property differs)
> > 
> > BR, Jarkko
>
> Yes that combination is possible.
>
> Pluton TPM uses the tpm_crb driver.

Then I guess we'll go with this for now. Thanks for the effort.

Tested-by: Jarkko Sakkinen <jarkko@...nel.org> # QEMU + swtpm
Reviewed-by: Jarkko Sakkinen <jarkko@...nel.org>

I'm planning to send a pull request right after this with the fix so it
will land to v6.6-rc1 or v6.6-rc2:
https://lore.kernel.org/linux-integrity/20230817201935.31399-1-jarkko@kernel.org/

BR, Jarkko