linux-integrity.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: Problem with the kernels trusted module on "inactive" TPM
       [not found] <CACnrVGfhkpsSWbCai4+5WEOhRukEr7JWDUnFdM-5D+FUyov+nQ@mail.gmail.com>
@ 2019-07-01 14:22 ` Roberto Sassu
  2019-07-04 10:42   ` Jarkko Sakkinen
  0 siblings, 1 reply; 4+ messages in thread
From: Roberto Sassu @ 2019-07-01 14:22 UTC (permalink / raw)
  To: CrazyT, keyrings, Jarkko Sakkinen; +Cc: linux-integrity

Adding to the discussion Jarkko (the maintainer of the trusted key) and
the linux-integrity mailing list.


On 6/27/2019 7:59 PM, CrazyT wrote:
> Hi,
> 
> 
> some people (including me) have problems with the "trusted" kernel module.
> As a result to this also the ecryptfs-module won't load.
> (https://bugs.archlinux.org/task/62678)
> If you use an "inactive" TPM module, the "trusted" module won't load anymore.
> The command modprobe just responds with "Bad address".
> The strace-command shows that init_module fails with EFAULT.
> I believe the reason for this is that the trusted-module handles
> inactive modules the same as active modules.
> This results in an error.
> 
> For example:
> https://github.com/torvalds/linux/commit/0b6cf6b97b7ef1fa3c7fefab0cac897a1c4a3400#diff-c01228e6d386afb29df6aac17d9dd7abR1251
> 
> My guess is that init_digests(); returns EFAULT in that case.
> The " if (!chip)" check above probably needs to check if the chip is "inactive".
> 
> "inactive" = still visible to the system, but not functional.
> It seems to be the default bios-setting for TPM on thinkpad.
> (btw.: i have no clue why anybody would need something like that)
> 
> Sadly i have no idea how you would check for an inactive chip,else i
> would have send a patch instead.
> But I hope the info i wrote is enough to get it fixed by somebody.

Thanks for the report. If you see -EFAULT, tpm_get_random() is probably
returning 0.

Jarkko, we could consider it as non-critical error, and handle it as if
the TPM is not found. What do you think?

Roberto

-- 
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Bo PENG, Jian LI, Yanli SHI

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

* Re: Problem with the kernels trusted module on "inactive" TPM
  2019-07-01 14:22 ` Problem with the kernels trusted module on "inactive" TPM Roberto Sassu
@ 2019-07-04 10:42   ` Jarkko Sakkinen
  2019-07-04 12:25     ` Roberto Sassu
  0 siblings, 1 reply; 4+ messages in thread
From: Jarkko Sakkinen @ 2019-07-04 10:42 UTC (permalink / raw)
  To: Roberto Sassu, CrazyT, keyrings; +Cc: linux-integrity, jejb, zohar

On Mon, 2019-07-01 at 17:22 +0300, Roberto Sassu wrote:
> Adding to the discussion Jarkko (the maintainer of the trusted key) and
> the linux-integrity mailing list.

I'm a co-maintainer (added James and Mimi).

> > some people (including me) have problems with the "trusted" kernel module.
> > As a result to this also the ecryptfs-module won't load.
> > (https://bugs.archlinux.org/task/62678)
> > If you use an "inactive" TPM module, the "trusted" module won't load
> > anymore.
> > The command modprobe just responds with "Bad address".
> > The strace-command shows that init_module fails with EFAULT.
> > I believe the reason for this is that the trusted-module handles
> > inactive modules the same as active modules.
> > This results in an error.
> > 
> > For example:
> > 
https://github.com/torvalds/linux/commit/0b6cf6b97b7ef1fa3c7fefab0cac897a1c4a3400#diff-c01228e6d386afb29df6aac17d9dd7abR1251
> > 
> > My guess is that init_digests(); returns EFAULT in that case.
> > The " if (!chip)" check above probably needs to check if the chip is
> > "inactive".
> > 
> > "inactive" = still visible to the system, but not functional.
> > It seems to be the default bios-setting for TPM on thinkpad.
> > (btw.: i have no clue why anybody would need something like that)
> > 
> > Sadly i have no idea how you would check for an inactive chip,else i
> > would have send a patch instead.
> > But I hope the info i wrote is enough to get it fixed by somebody.
> 
> Thanks for the report. If you see -EFAULT, tpm_get_random() is probably
> returning 0.
> 
> Jarkko, we could consider it as non-critical error, and handle it as if
> the TPM is not found. What do you think?

Not sure I get this. Wasn't the issue fixed in c78719203fc6 or is there
something missing?

/Jarkko


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

* Re: Problem with the kernels trusted module on "inactive" TPM
  2019-07-04 10:42   ` Jarkko Sakkinen
@ 2019-07-04 12:25     ` Roberto Sassu
  2019-07-04 12:42       ` Mimi Zohar
  0 siblings, 1 reply; 4+ messages in thread
From: Roberto Sassu @ 2019-07-04 12:25 UTC (permalink / raw)
  To: Jarkko Sakkinen, CrazyT, keyrings; +Cc: linux-integrity, jejb, zohar

On 7/4/2019 12:42 PM, Jarkko Sakkinen wrote:
> On Mon, 2019-07-01 at 17:22 +0300, Roberto Sassu wrote:
>> Adding to the discussion Jarkko (the maintainer of the trusted key) and
>> the linux-integrity mailing list.
> 
> I'm a co-maintainer (added James and Mimi).
> 
>>> some people (including me) have problems with the "trusted" kernel module.
>>> As a result to this also the ecryptfs-module won't load.
>>> (https://bugs.archlinux.org/task/62678)
>>> If you use an "inactive" TPM module, the "trusted" module won't load
>>> anymore.
>>> The command modprobe just responds with "Bad address".
>>> The strace-command shows that init_module fails with EFAULT.
>>> I believe the reason for this is that the trusted-module handles
>>> inactive modules the same as active modules.
>>> This results in an error.
>>>
>>> For example:
>>>
> https://github.com/torvalds/linux/commit/0b6cf6b97b7ef1fa3c7fefab0cac897a1c4a3400#diff-c01228e6d386afb29df6aac17d9dd7abR1251
>>>
>>> My guess is that init_digests(); returns EFAULT in that case.
>>> The " if (!chip)" check above probably needs to check if the chip is
>>> "inactive".
>>>
>>> "inactive" = still visible to the system, but not functional.
>>> It seems to be the default bios-setting for TPM on thinkpad.
>>> (btw.: i have no clue why anybody would need something like that)
>>>
>>> Sadly i have no idea how you would check for an inactive chip,else i
>>> would have send a patch instead.
>>> But I hope the info i wrote is enough to get it fixed by somebody.
>>
>> Thanks for the report. If you see -EFAULT, tpm_get_random() is probably
>> returning 0.
>>
>> Jarkko, we could consider it as non-critical error, and handle it as if
>> the TPM is not found. What do you think?
> 
> Not sure I get this. Wasn't the issue fixed in c78719203fc6 or is there
> something missing?

It seems it is not enough. A TPM is found but does not return data to
tpm_get_random(), I think.

Roberto

-- 
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Bo PENG, Jian LI, Yanli SHI

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

* Re: Problem with the kernels trusted module on "inactive" TPM
  2019-07-04 12:25     ` Roberto Sassu
@ 2019-07-04 12:42       ` Mimi Zohar
  0 siblings, 0 replies; 4+ messages in thread
From: Mimi Zohar @ 2019-07-04 12:42 UTC (permalink / raw)
  To: Roberto Sassu, Jarkko Sakkinen, CrazyT, keyrings
  Cc: linux-integrity, jejb, Nayna Jain

[Cc'ing Nayna]

On Thu, 2019-07-04 at 14:25 +0200, Roberto Sassu wrote:
> On 7/4/2019 12:42 PM, Jarkko Sakkinen wrote:
> > On Mon, 2019-07-01 at 17:22 +0300, Roberto Sassu wrote:
> >> Adding to the discussion Jarkko (the maintainer of the trusted key) and
> >> the linux-integrity mailing list.
> > 
> > I'm a co-maintainer (added James and Mimi).
> > 
> >>> some people (including me) have problems with the "trusted" kernel module.
> >>> As a result to this also the ecryptfs-module won't load.
> >>> (https://bugs.archlinux.org/task/62678)
> >>> If you use an "inactive" TPM module, the "trusted" module won't load
> >>> anymore.
> >>> The command modprobe just responds with "Bad address".
> >>> The strace-command shows that init_module fails with EFAULT.
> >>> I believe the reason for this is that the trusted-module handles
> >>> inactive modules the same as active modules.
> >>> This results in an error.
> >>>
> >>> For example:
> >>>
> > https://github.com/torvalds/linux/commit/0b6cf6b97b7ef1fa3c7fefab0cac897a1c4a3400#diff-c01228e6d386afb29df6aac17d9dd7abR1251
> >>>
> >>> My guess is that init_digests(); returns EFAULT in that case.
> >>> The " if (!chip)" check above probably needs to check if the chip is
> >>> "inactive".
> >>>
> >>> "inactive" = still visible to the system, but not functional.
> >>> It seems to be the default bios-setting for TPM on thinkpad.
> >>> (btw.: i have no clue why anybody would need something like that)
> >>>
> >>> Sadly i have no idea how you would check for an inactive chip,else i
> >>> would have send a patch instead.
> >>> But I hope the info i wrote is enough to get it fixed by somebody.
> >>
> >> Thanks for the report. If you see -EFAULT, tpm_get_random() is probably
> >> returning 0.
> >>
> >> Jarkko, we could consider it as non-critical error, and handle it as if
> >> the TPM is not found. What do you think?
> > 
> > Not sure I get this. Wasn't the issue fixed in c78719203fc6 or is there
> > something missing?
> 
> It seems it is not enough. A TPM is found but does not return data to
> tpm_get_random(), I think.

While working with Nayna (and George) on the "tpm: fixes uninitialized
allocated banks for IBM vtpm driver" patch, I wondered what happens if
the chip is enabled, but none of the banks were enabled.  Could this
be the "inactive" state?

Mimi


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

end of thread, other threads:[~2019-07-04 12:42 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <CACnrVGfhkpsSWbCai4+5WEOhRukEr7JWDUnFdM-5D+FUyov+nQ@mail.gmail.com>
2019-07-01 14:22 ` Problem with the kernels trusted module on "inactive" TPM Roberto Sassu
2019-07-04 10:42   ` Jarkko Sakkinen
2019-07-04 12:25     ` Roberto Sassu
2019-07-04 12:42       ` Mimi Zohar

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).