All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mimi Zohar <zohar@linux.ibm.com>
To: Roberto Sassu <roberto.sassu@huawei.com>,
	Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
	CrazyT <crazyt2019+lml@gmail.com>,
	keyrings@vger.kernel.org
Cc: "linux-integrity@vger.kernel.org"
	<linux-integrity@vger.kernel.org>,
	jejb@linux.ibm.com, Nayna Jain <nayna@linux.ibm.com>
Subject: Re: Problem with the kernels trusted module on "inactive" TPM
Date: Thu, 04 Jul 2019 12:42:05 +0000	[thread overview]
Message-ID: <1562244125.6165.95.camel@linux.ibm.com> (raw)
In-Reply-To: <cb46e05d-f9bd-2d58-0996-390cfbf6f786@huawei.com>

[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

WARNING: multiple messages have this Message-ID (diff)
From: Mimi Zohar <zohar@linux.ibm.com>
To: Roberto Sassu <roberto.sassu@huawei.com>,
	Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
	CrazyT <crazyt2019+lml@gmail.com>,
	keyrings@vger.kernel.org
Cc: "linux-integrity@vger.kernel.org"
	<linux-integrity@vger.kernel.org>,
	jejb@linux.ibm.com, Nayna Jain <nayna@linux.ibm.com>
Subject: Re: Problem with the kernels trusted module on "inactive" TPM
Date: Thu, 04 Jul 2019 08:42:05 -0400	[thread overview]
Message-ID: <1562244125.6165.95.camel@linux.ibm.com> (raw)
In-Reply-To: <cb46e05d-f9bd-2d58-0996-390cfbf6f786@huawei.com>

[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


  reply	other threads:[~2019-07-04 12:42 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-27 16:59 Problem with the kernels trusted module on "inactive" TPM CrazyT
2019-07-01 14:22 ` Roberto Sassu
2019-07-01 14:22   ` Roberto Sassu
2019-07-04 10:42   ` Jarkko Sakkinen
2019-07-04 10:42     ` Jarkko Sakkinen
2019-07-04 12:25     ` Roberto Sassu
2019-07-04 12:25       ` Roberto Sassu
2019-07-04 12:42       ` Mimi Zohar [this message]
2019-07-04 12:42         ` Mimi Zohar

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=1562244125.6165.95.camel@linux.ibm.com \
    --to=zohar@linux.ibm.com \
    --cc=crazyt2019+lml@gmail.com \
    --cc=jarkko.sakkinen@linux.intel.com \
    --cc=jejb@linux.ibm.com \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=nayna@linux.ibm.com \
    --cc=roberto.sassu@huawei.com \
    /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.