The vendor check introduced by commit 554b841d4703 ("tpm: Disable RNG for all AMD fTPMs") doesn't work properly on Intel fTPM. The TPM doesn't reply at bootup and returns back the command code.
As this isn't crucial for anything but AMD fTPM and AMD fTPM works, throw away the error code to let Intel fTPM continue to work.
Cc: stable@vger.kernel.org Fixes: 554b841d4703 ("tpm: Disable RNG for all AMD fTPMs") Reported-by: Todd Brandt todd.e.brandt@intel.com Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217804 Signed-off-by: Mario Limonciello mario.limonciello@amd.com --- drivers/char/tpm/tpm_crb.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c index 9eb1a18590123..b0e9931fe436c 100644 --- a/drivers/char/tpm/tpm_crb.c +++ b/drivers/char/tpm/tpm_crb.c @@ -472,8 +472,7 @@ static int crb_check_flags(struct tpm_chip *chip) if (ret) return ret;
- ret = tpm2_get_tpm_pt(chip, TPM2_PT_MANUFACTURER, &val, NULL); - if (ret) + if (tpm2_get_tpm_pt(chip, TPM2_PT_MANUFACTURER, &val, NULL)) goto release;
if (val == 0x414D4400U /* AMD */)
On Fri Aug 18, 2023 at 6:15 PM UTC, Mario Limonciello wrote:
The vendor check introduced by commit 554b841d4703 ("tpm: Disable RNG for all AMD fTPMs") doesn't work properly on Intel fTPM. The TPM doesn't reply at bootup and returns back the command code.
Is this reproducible with any production hardware? You are stating it as it was reproducible categorically with any Intel fTPM.
As this isn't crucial for anything but AMD fTPM and AMD fTPM works, throw away the error code to let Intel fTPM continue to work.
Cc: stable@vger.kernel.org Fixes: 554b841d4703 ("tpm: Disable RNG for all AMD fTPMs")
It does make sense not to exercise this outside of AMD CPus but since there is no production hardware failing, it cannot be categorized as a bug fix.
Reported-by: Todd Brandt todd.e.brandt@intel.com Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217804 Signed-off-by: Mario Limonciello mario.limonciello@amd.com
drivers/char/tpm/tpm_crb.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c index 9eb1a18590123..b0e9931fe436c 100644 --- a/drivers/char/tpm/tpm_crb.c +++ b/drivers/char/tpm/tpm_crb.c @@ -472,8 +472,7 @@ static int crb_check_flags(struct tpm_chip *chip) if (ret) return ret;
- ret = tpm2_get_tpm_pt(chip, TPM2_PT_MANUFACTURER, &val, NULL);
- if (ret)
- if (tpm2_get_tpm_pt(chip, TPM2_PT_MANUFACTURER, &val, NULL)) goto release;
It would be better not to exercise a potentially failing code path at all. This initiates full transaction with the TPM.
if (val == 0x414D4400U /* AMD */) -- 2.34.1
BR, Jarkko
On 8/18/2023 5:07 PM, Jarkko Sakkinen wrote:
On Fri Aug 18, 2023 at 6:15 PM UTC, Mario Limonciello wrote:
The vendor check introduced by commit 554b841d4703 ("tpm: Disable RNG for all AMD fTPMs") doesn't work properly on Intel fTPM. The TPM doesn't reply at bootup and returns back the command code.
Is this reproducible with any production hardware? You are stating it as it was reproducible categorically with any Intel fTPM.
Yes, it's affecting production hardware too. Someone came to the kernel bugzilla and reported a regression on 6.4.11 on a Lenovo Intel laptop as well.
As this isn't crucial for anything but AMD fTPM and AMD fTPM works, throw away the error code to let Intel fTPM continue to work.
Cc: stable@vger.kernel.org Fixes: 554b841d4703 ("tpm: Disable RNG for all AMD fTPMs")
It does make sense not to exercise this outside of AMD CPus but since there is no production hardware failing, it cannot be categorized as a bug fix.
See above (and also kernel bugzilla).
Reported-by: Todd Brandt todd.e.brandt@intel.com Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217804 Signed-off-by: Mario Limonciello mario.limonciello@amd.com
drivers/char/tpm/tpm_crb.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c index 9eb1a18590123..b0e9931fe436c 100644 --- a/drivers/char/tpm/tpm_crb.c +++ b/drivers/char/tpm/tpm_crb.c @@ -472,8 +472,7 @@ static int crb_check_flags(struct tpm_chip *chip) if (ret) return ret;
- ret = tpm2_get_tpm_pt(chip, TPM2_PT_MANUFACTURER, &val, NULL);
- if (ret)
- if (tpm2_get_tpm_pt(chip, TPM2_PT_MANUFACTURER, &val, NULL)) goto release;
It would be better not to exercise a potentially failing code path at all. This initiates full transaction with the TPM.
So why does a full transaction not work in this case?
if (val == 0x414D4400U /* AMD */) -- 2.34.1
BR, Jarkko
On Fri Aug 18, 2023 at 10:38 PM UTC, Limonciello, Mario wrote:
On 8/18/2023 5:07 PM, Jarkko Sakkinen wrote:
On Fri Aug 18, 2023 at 6:15 PM UTC, Mario Limonciello wrote:
The vendor check introduced by commit 554b841d4703 ("tpm: Disable RNG for all AMD fTPMs") doesn't work properly on Intel fTPM. The TPM doesn't reply at bootup and returns back the command code.
Is this reproducible with any production hardware? You are stating it as it was reproducible categorically with any Intel fTPM.
Yes, it's affecting production hardware too. Someone came to the kernel bugzilla and reported a regression on 6.4.11 on a Lenovo Intel laptop as well.
Now the description says that cateogrically all Intel fTPM's fail.
I asked for the laptop model in the bugzilla bug, which should be put to the commit description later on (hopefully with a snippet of klog transcript). This commit cannot be applied as it is at the moment, even if it turned out to be a legit fix.
As this isn't crucial for anything but AMD fTPM and AMD fTPM works, throw away the error code to let Intel fTPM continue to work.
Cc: stable@vger.kernel.org Fixes: 554b841d4703 ("tpm: Disable RNG for all AMD fTPMs")
It does make sense not to exercise this outside of AMD CPus but since there is no production hardware failing, it cannot be categorized as a bug fix.
See above (and also kernel bugzilla).
Reported-by: Todd Brandt todd.e.brandt@intel.com Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217804 Signed-off-by: Mario Limonciello mario.limonciello@amd.com
drivers/char/tpm/tpm_crb.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c index 9eb1a18590123..b0e9931fe436c 100644 --- a/drivers/char/tpm/tpm_crb.c +++ b/drivers/char/tpm/tpm_crb.c @@ -472,8 +472,7 @@ static int crb_check_flags(struct tpm_chip *chip) if (ret) return ret;
- ret = tpm2_get_tpm_pt(chip, TPM2_PT_MANUFACTURER, &val, NULL);
- if (ret)
- if (tpm2_get_tpm_pt(chip, TPM2_PT_MANUFACTURER, &val, NULL)) goto release;
It would be better not to exercise a potentially failing code path at all. This initiates full transaction with the TPM.
So why does a full transaction not work in this case?
It makes absolutely zero sense to send a message to a TPM just to know that you are on AMD CPU, right?
E.g. you could check if boot_cpu_data.x86_vendor == X86_VENDOR_AMD right in the beginning of this function.
BR, Jarkko
On 8/18/2023 6:44 PM, Jarkko Sakkinen wrote:
On Fri Aug 18, 2023 at 10:38 PM UTC, Limonciello, Mario wrote:
On 8/18/2023 5:07 PM, Jarkko Sakkinen wrote:
On Fri Aug 18, 2023 at 6:15 PM UTC, Mario Limonciello wrote:
The vendor check introduced by commit 554b841d4703 ("tpm: Disable RNG for all AMD fTPMs") doesn't work properly on Intel fTPM. The TPM doesn't reply at bootup and returns back the command code.
Is this reproducible with any production hardware? You are stating it as it was reproducible categorically with any Intel fTPM.
Yes, it's affecting production hardware too. Someone came to the kernel bugzilla and reported a regression on 6.4.11 on a Lenovo Intel laptop as well.
Now the description says that cateogrically all Intel fTPM's fail.
According to Todd this change caused 5 *different* reference Intel systems all to fail. I know they're not production hardware, but still..
I asked for the laptop model in the bugzilla bug, which should be put to the commit description later on (hopefully with a snippet of klog transcript). This commit cannot be applied as it is at the moment, even if it turned out to be a legit fix.
As this isn't crucial for anything but AMD fTPM and AMD fTPM works, throw away the error code to let Intel fTPM continue to work.
Cc: stable@vger.kernel.org Fixes: 554b841d4703 ("tpm: Disable RNG for all AMD fTPMs")
It does make sense not to exercise this outside of AMD CPus but since there is no production hardware failing, it cannot be categorized as a bug fix.
See above (and also kernel bugzilla).
Reported-by: Todd Brandt todd.e.brandt@intel.com Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217804 Signed-off-by: Mario Limonciello mario.limonciello@amd.com
drivers/char/tpm/tpm_crb.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c index 9eb1a18590123..b0e9931fe436c 100644 --- a/drivers/char/tpm/tpm_crb.c +++ b/drivers/char/tpm/tpm_crb.c @@ -472,8 +472,7 @@ static int crb_check_flags(struct tpm_chip *chip) if (ret) return ret;
- ret = tpm2_get_tpm_pt(chip, TPM2_PT_MANUFACTURER, &val, NULL);
- if (ret)
- if (tpm2_get_tpm_pt(chip, TPM2_PT_MANUFACTURER, &val, NULL)) goto release;
It would be better not to exercise a potentially failing code path at all. This initiates full transaction with the TPM.
So why does a full transaction not work in this case?
It makes absolutely zero sense to send a message to a TPM just to know that you are on AMD CPU, right?
E.g. you could check if boot_cpu_data.x86_vendor == X86_VENDOR_AMD right in the beginning of this function.
You couldn't replace the whole function with this check.
If you apply it to everything on an AMD system you catch too much. You need to know it's specifically an AMD fTPM to avoid tripping the stutter bug. Pluton is fine, dTPMs are fine too.
On Fri, Aug 18, 2023 at 06:57:57PM -0500, Limonciello, Mario wrote:
On 8/18/2023 6:44 PM, Jarkko Sakkinen wrote:
On Fri Aug 18, 2023 at 10:38 PM UTC, Limonciello, Mario wrote:
On 8/18/2023 5:07 PM, Jarkko Sakkinen wrote:
On Fri Aug 18, 2023 at 6:15 PM UTC, Mario Limonciello wrote:
The vendor check introduced by commit 554b841d4703 ("tpm: Disable RNG for all AMD fTPMs") doesn't work properly on Intel fTPM. The TPM doesn't reply at bootup and returns back the command code.
Is this reproducible with any production hardware? You are stating it as it was reproducible categorically with any Intel fTPM.
Yes, it's affecting production hardware too. Someone came to the kernel bugzilla and reported a regression on 6.4.11 on a Lenovo Intel laptop as well.
Now the description says that cateogrically all Intel fTPM's fail.
According to Todd this change caused 5 *different* reference Intel systems all to fail. I know they're not production hardware, but still..
For what it's worth, I can confirm that this issue also occurs on an ASUS Z170I motherboard with Intel i3 7100U and an integrated fTPM. If it helps I'm happy to try out the proposed patch -- for now I simply reverted 554b841d4703 ("tpm: Disable RNG for all AMD fTPMs"), which resolved the issue for me.
Patrick
On Sat Aug 19, 2023 at 2:57 AM EEST, Limonciello, Mario wrote:
On 8/18/2023 6:44 PM, Jarkko Sakkinen wrote:
On Fri Aug 18, 2023 at 10:38 PM UTC, Limonciello, Mario wrote:
On 8/18/2023 5:07 PM, Jarkko Sakkinen wrote:
On Fri Aug 18, 2023 at 6:15 PM UTC, Mario Limonciello wrote:
The vendor check introduced by commit 554b841d4703 ("tpm: Disable RNG for all AMD fTPMs") doesn't work properly on Intel fTPM. The TPM doesn't reply at bootup and returns back the command code.
Is this reproducible with any production hardware? You are stating it as it was reproducible categorically with any Intel fTPM.
Yes, it's affecting production hardware too. Someone came to the kernel bugzilla and reported a regression on 6.4.11 on a Lenovo Intel laptop as well.
Now the description says that cateogrically all Intel fTPM's fail.
According to Todd this change caused 5 *different* reference Intel systems all to fail. I know they're not production hardware, but still..
Kind of sane requirement is to scope on known systems that exists. We are not fixing bugs for R&D platforms.
I asked for the laptop model in the bugzilla bug, which should be put to the commit description later on (hopefully with a snippet of klog transcript). This commit cannot be applied as it is at the moment, even if it turned out to be a legit fix.
As this isn't crucial for anything but AMD fTPM and AMD fTPM works, throw away the error code to let Intel fTPM continue to work.
Cc: stable@vger.kernel.org Fixes: 554b841d4703 ("tpm: Disable RNG for all AMD fTPMs")
It does make sense not to exercise this outside of AMD CPus but since there is no production hardware failing, it cannot be categorized as a bug fix.
See above (and also kernel bugzilla).
Reported-by: Todd Brandt todd.e.brandt@intel.com Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217804 Signed-off-by: Mario Limonciello mario.limonciello@amd.com
drivers/char/tpm/tpm_crb.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c index 9eb1a18590123..b0e9931fe436c 100644 --- a/drivers/char/tpm/tpm_crb.c +++ b/drivers/char/tpm/tpm_crb.c @@ -472,8 +472,7 @@ static int crb_check_flags(struct tpm_chip *chip) if (ret) return ret;
- ret = tpm2_get_tpm_pt(chip, TPM2_PT_MANUFACTURER, &val, NULL);
- if (ret)
- if (tpm2_get_tpm_pt(chip, TPM2_PT_MANUFACTURER, &val, NULL)) goto release;
It would be better not to exercise a potentially failing code path at all. This initiates full transaction with the TPM.
So why does a full transaction not work in this case?
It makes absolutely zero sense to send a message to a TPM just to know that you are on AMD CPU, right?
E.g. you could check if boot_cpu_data.x86_vendor == X86_VENDOR_AMD right in the beginning of this function.
You couldn't replace the whole function with this check.
If you apply it to everything on an AMD system you catch too much. You need to know it's specifically an AMD fTPM to avoid tripping the stutter bug. Pluton is fine, dTPMs are fine too.
dTPM's have nothing to be with tpm_crb. They use tpm_tis_core.
Is there a system with CPU recognized as AMD and *firmware* TPM from some 3rd party vendor? If not, then you could also drop tpm2_get_tpm_pt() altogether.
BR, Jarkko
On 8/18/23 14:15, Mario Limonciello wrote:
The vendor check introduced by commit 554b841d4703 ("tpm: Disable RNG for all AMD fTPMs") doesn't work properly on Intel fTPM. The TPM doesn't reply at bootup and returns back the command code.
As this isn't crucial for anything but AMD fTPM and AMD fTPM works, throw away the error code to let Intel fTPM continue to work.
FWIW there is a Fedora bug where several people are reporting similar issues: https://bugzilla.redhat.com/show_bug.cgi?id=2232888
Dusty
On Mon Aug 28, 2023 at 6:47 PM EEST, Dusty Mabe wrote:
On 8/18/23 14:15, Mario Limonciello wrote:
The vendor check introduced by commit 554b841d4703 ("tpm: Disable RNG for all AMD fTPMs") doesn't work properly on Intel fTPM. The TPM doesn't reply at bootup and returns back the command code.
As this isn't crucial for anything but AMD fTPM and AMD fTPM works, throw away the error code to let Intel fTPM continue to work.
FWIW there is a Fedora bug where several people are reporting similar issues: https://bugzilla.redhat.com/show_bug.cgi?id=2232888
Dusty
I just sent v4 with reported-by's added despite:
1. checkpatch.pl complaining about them 2. no mention of the bugzilla in the kernel documentation at least not in the sections describing the process handling the patches
BR, Jarkko
linux-stable-mirror@lists.linaro.org
-
Dusty Mabe -
Jarkko Sakkinen -
Limonciello, Mario -
Mario Limonciello
-
Patrick Steinhardt