linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [Regression] TPM char device not created if TPM 1.2 is disabled, but visible
@ 2018-03-03 21:27 Sahil Rihan
  2018-03-05 12:14 ` Jarkko Sakkinen
  0 siblings, 1 reply; 5+ messages in thread
From: Sahil Rihan @ 2018-03-03 21:27 UTC (permalink / raw)
  To: linux-kernel; +Cc: Alexei Starovoitov, Jarkko Sakkinen, Jason Gunthorpe

(Please CC me on replies - I'm not subscribed to LMKL)

Prior to  0cf577a03f21 if a TPM 1.2 device was disabled, but visible (sysfs node "enabled" returns 0), creation of the TPM char device was only skipped if  tpm_bios_log_setup returned -ENODEV. 

On some systems like HP DL380 G9, if the TPM is disabled but visible, the TCPA log is empty, which means tpm_read_log_acpi returns -EIO.  Starting with 0cf577a03f21, -EIO triggers an early return from tpm_chip_register which means the char device is not created.

Log snippet:
[    4.320387] tpm_tis 00:00: 1.2 TPM (device-id 0xB, rev-id 16)
[    4.455389] tpm tpm0: A TPM error (7) occurred attempting to read a pcr value
[    4.457762] tpm tpm0: TPM is disabled/deactivated (0x7)
[    4.459461] tpm tpm0: tpm_read_log_acpi: TCPA log area empty    <----------------------
[    4.461312] tpm_tis: probe of 00:00 failed with error -5

Thanks,
Sahil

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Regression] TPM char device not created if TPM 1.2 is disabled, but visible
  2018-03-03 21:27 [Regression] TPM char device not created if TPM 1.2 is disabled, but visible Sahil Rihan
@ 2018-03-05 12:14 ` Jarkko Sakkinen
  2018-03-05 19:28   ` Sahil Rihan
  0 siblings, 1 reply; 5+ messages in thread
From: Jarkko Sakkinen @ 2018-03-05 12:14 UTC (permalink / raw)
  To: Sahil Rihan; +Cc: linux-kernel, Alexei Starovoitov, Jason Gunthorpe

On Sat, Mar 03, 2018 at 09:27:36PM +0000, Sahil Rihan wrote:
> (Please CC me on replies - I'm not subscribed to LMKL)
> 
> Prior to  0cf577a03f21 if a TPM 1.2 device was disabled, but visible (sysfs node "enabled" returns 0), creation of the TPM char device was only skipped if  tpm_bios_log_setup returned -ENODEV. 
> 
> On some systems like HP DL380 G9, if the TPM is disabled but visible, the TCPA log is empty, which means tpm_read_log_acpi returns -EIO.  Starting with 0cf577a03f21, -EIO triggers an early return from tpm_chip_register which means the char device is not created.
> 
> Log snippet:
> [    4.320387] tpm_tis 00:00: 1.2 TPM (device-id 0xB, rev-id 16)
> [    4.455389] tpm tpm0: A TPM error (7) occurred attempting to read a pcr value
> [    4.457762] tpm tpm0: TPM is disabled/deactivated (0x7)
> [    4.459461] tpm tpm0: tpm_read_log_acpi: TCPA log area empty    <----------------------
> [    4.461312] tpm_tis: probe of 00:00 failed with error -5
> 
> Thanks,
> Sahil

Thanks for the bug report, I appreciate it!

Personally I think we should keep the warning if the log area is empt
but tpm_read_log_acpi() should return -ENODEV in this case.

/Jarkko

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Regression] TPM char device not created if TPM 1.2 is disabled, but visible
  2018-03-05 12:14 ` Jarkko Sakkinen
@ 2018-03-05 19:28   ` Sahil Rihan
  2018-03-06 11:13     ` Jarkko Sakkinen
  0 siblings, 1 reply; 5+ messages in thread
From: Sahil Rihan @ 2018-03-05 19:28 UTC (permalink / raw)
  To: Jarkko Sakkinen; +Cc: linux-kernel, Alexei Starovoitov, Jason Gunthorpe

> On Sat, Mar 03, 2018 at 09:27:36PM +0000, Sahil Rihan wrote:
> > (Please CC me on replies - I'm not subscribed to LMKL)
> > 
> > Prior to  0cf577a03f21 if a TPM 1.2 device was disabled, but visible (sysfs node "enabled" returns 0), creation of the TPM char device was only skipped if  tpm_bios_log_setup returned -ENODEV. 
> > 
> > On some systems like HP DL380 G9, if the TPM is disabled but visible, the TCPA log is empty, which means tpm_read_log_acpi returns -EIO.  Starting with 0cf577a03f21, -EIO triggers an early return from tpm_chip_register which means the char device is not created.
> > 
> > Log snippet:
> > [    4.320387] tpm_tis 00:00: 1.2 TPM (device-id 0xB, rev-id 16)
> > [    4.455389] tpm tpm0: A TPM error (7) occurred attempting to read a pcr value
> > [    4.457762] tpm tpm0: TPM is disabled/deactivated (0x7)
> > [    4.459461] tpm tpm0: tpm_read_log_acpi: TCPA log area empty    <----------------------
> > [    4.461312] tpm_tis: probe of 00:00 failed with error -5
> > 
> > Thanks,
> > Sahil
>
> Thanks for the bug report, I appreciate it!
> 
> Personally I think we should keep the warning if the log area is empt
> but tpm_read_log_acpi() should return -ENODEV in this case.
> 
> /Jarkko

Agree on keeping the warning. 

I'm guessing you want to return -ENODEV from tpm_bios_log_setup. Doing it from tpm_read_log_acpi will just fall through to calling tpm_read_log_of, which I think will end up returning -EIO again.

In terms of semantics I'm not sure if -ENODEV is the right return code if the BIOS event log is absent. I guess you can claim it's some sort of "device". I don’t have a strong opinion here.

Sahil

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Regression] TPM char device not created if TPM 1.2 is disabled, but visible
  2018-03-05 19:28   ` Sahil Rihan
@ 2018-03-06 11:13     ` Jarkko Sakkinen
  2018-03-07 22:34       ` Sahil Rihan
  0 siblings, 1 reply; 5+ messages in thread
From: Jarkko Sakkinen @ 2018-03-06 11:13 UTC (permalink / raw)
  To: Sahil Rihan; +Cc: linux-kernel, Alexei Starovoitov, Jason Gunthorpe

On Mon, 2018-03-05 at 19:28 +0000, Sahil Rihan wrote:
> Agree on keeping the warning. 
> 
> I'm guessing you want to return -ENODEV from tpm_bios_log_setup. Doing it from
> tpm_read_log_acpi will just fall through to calling tpm_read_log_of, which I
> think will end up returning -EIO again.
> 
> In terms of semantics I'm not sure if -ENODEV is the right return code if the
> BIOS event log is absent. I guess you can claim it's some sort of "device". I
> don’t have a strong opinion here.
> 
> Sahil

You are absolutely right. Printing warning and returning zero would be
the right measure to take.

One more cosmetic detail. Should the log level be info or warn? I mean
as far as I'm concerned everything is in a legit state.

/Jarkko

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Regression] TPM char device not created if TPM 1.2 is disabled, but visible
  2018-03-06 11:13     ` Jarkko Sakkinen
@ 2018-03-07 22:34       ` Sahil Rihan
  0 siblings, 0 replies; 5+ messages in thread
From: Sahil Rihan @ 2018-03-07 22:34 UTC (permalink / raw)
  To: Jarkko Sakkinen; +Cc: linux-kernel, Alexei Starovoitov, Jason Gunthorpe

> On 3/6/18, 3:14 AM, "Jarkko Sakkinen" <jarkko.sakkinen@linux.intel.com> wrote:
> 
>   On Mon, 2018-03-05 at 19:28 +0000, Sahil Rihan wrote:
> > Agree on keeping the warning. 
> > 
> > I'm guessing you want to return -ENODEV from tpm_bios_log_setup. Doing it from
> > tpm_read_log_acpi will just fall through to calling tpm_read_log_of, which I
> > think will end up returning -EIO again.
> > 
> > In terms of semantics I'm not sure if -ENODEV is the right return code if the
> > BIOS event log is absent. I guess you can claim it's some sort of "device". I
> > don’t have a strong opinion here.
> > 
> > Sahil
>     
> You are absolutely right. Printing warning and returning zero would be
> the right measure to take.
>     
> One more cosmetic detail. Should the log level be info or warn? I mean
> as far as I'm concerned everything is in a legit state.
>     
> /Jarkko
   
Yeah, I tend to agree. I think INFO should be fine. 

My reasoning is as follows: if the TPM is disabled, you shouldn't really be checking/using the BIOS event log measurements anyway. 

Sahil
 

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2018-03-07 22:34 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-03-03 21:27 [Regression] TPM char device not created if TPM 1.2 is disabled, but visible Sahil Rihan
2018-03-05 12:14 ` Jarkko Sakkinen
2018-03-05 19:28   ` Sahil Rihan
2018-03-06 11:13     ` Jarkko Sakkinen
2018-03-07 22:34       ` Sahil Rihan

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).