All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tyler Hicks <tyhicks@canonical.com>
To: Roberto Sassu <roberto.sassu@huawei.com>
Cc: jarkko.sakkinen@linux.intel.com, jejb@linux.ibm.com,
	zohar@linux.ibm.com, jgg@ziepe.ca,
	linux-integrity@vger.kernel.org,
	linux-security-module@vger.kernel.org, keyrings@vger.kernel.org,
	linux-kernel@vger.kernel.org, crazyt2019+lml@gmail.com,
	nayna@linux.vnet.ibm.com, silviu.vlasceanu@huawei.com
Subject: Re: [PATCH v2] KEYS: trusted: allow module init if TPM is inactive or deactivated
Date: Fri, 02 Aug 2019 16:15:28 +0000	[thread overview]
Message-ID: <20190802161527.GC26616@elm> (raw)
In-Reply-To: <8baf1c39-ad04-5cd6-bc67-341e7411db16@huawei.com>

On 2019-08-02 18:11:09, Roberto Sassu wrote:
> On 8/2/2019 5:34 PM, Roberto Sassu wrote:
> > On 8/2/2019 5:30 PM, Tyler Hicks wrote:
> > > On 2019-08-02 17:07:33, Roberto Sassu wrote:
> > > > Commit c78719203fc6 ("KEYS: trusted: allow trusted.ko to
> > > > initialize w/o a
> > > > TPM") allows the trusted module to be loaded even a TPM is not found to
> > >                                                     ^ if
> > > 
> > > > avoid module dependency problems.
> > > > 
> > > > However, trusted module initialization can still fail if the TPM is
> > > > inactive or deactivated. This patch ignores tpm_get_random() errors in
> > > > init_digests() and returns -EFAULT in pcrlock() if the TPM didn't return
> > > > random data.
> > > > 
> > > > Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
> > > 
> > > The code changes look correct to me.
> > > 
> > >    Reviewed-by: Tyler Hicks <tyhicks@canonical.com>
> > > 
> > > For whoever takes this patch through their tree, I think that adding the
> > > following Fixes tag would be useful (as well as cc'ing stable):
> > > 
> > >    Fixes: 240730437deb ("KEYS: trusted: explicitly use tpm_chip
> > > structure...")
> > > 
> > > I think it is also worth leaving a short note, in the commit message,
> > > for backporters that commit 782779b60faa ("tpm: Actually fail on TPM
> > > errors during "get random"") should be included with any backports of
> > > this patch.
> > 
> > Right, thanks. I wait for Jarkko's comments and I add both the Fixes tag
> > and the short note in the next version of the patch.
> 
> Uhm, I was thinking that maybe it is not necessary to mention commit
> 782779b60faa. This patch would still return 0 even if that commit is not
> backported (TPM_ERR_DISABLED < TPM_MAX_DIGEST_SIZE).

The commit message for 782779b60faa shows 379 being returned when
attempting to get random:

  [   18.092103] tpm tpm0: A TPM error (379) occurred attempting get random

I don't know enough about TPM chips to know how common that is...

Tyler

> 
> Roberto
> 
> -- 
> HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
> Managing Director: Li Peng, Li Jian, Shi Yanli

WARNING: multiple messages have this Message-ID (diff)
From: Tyler Hicks <tyhicks@canonical.com>
To: Roberto Sassu <roberto.sassu@huawei.com>
Cc: jarkko.sakkinen@linux.intel.com, jejb@linux.ibm.com,
	zohar@linux.ibm.com, jgg@ziepe.ca,
	linux-integrity@vger.kernel.org,
	linux-security-module@vger.kernel.org, keyrings@vger.kernel.org,
	linux-kernel@vger.kernel.org, crazyt2019+lml@gmail.com,
	nayna@linux.vnet.ibm.com, silviu.vlasceanu@huawei.com
Subject: Re: [PATCH v2] KEYS: trusted: allow module init if TPM is inactive or deactivated
Date: Fri, 2 Aug 2019 11:15:28 -0500	[thread overview]
Message-ID: <20190802161527.GC26616@elm> (raw)
In-Reply-To: <8baf1c39-ad04-5cd6-bc67-341e7411db16@huawei.com>

On 2019-08-02 18:11:09, Roberto Sassu wrote:
> On 8/2/2019 5:34 PM, Roberto Sassu wrote:
> > On 8/2/2019 5:30 PM, Tyler Hicks wrote:
> > > On 2019-08-02 17:07:33, Roberto Sassu wrote:
> > > > Commit c78719203fc6 ("KEYS: trusted: allow trusted.ko to
> > > > initialize w/o a
> > > > TPM") allows the trusted module to be loaded even a TPM is not found to
> > >                                                     ^ if
> > > 
> > > > avoid module dependency problems.
> > > > 
> > > > However, trusted module initialization can still fail if the TPM is
> > > > inactive or deactivated. This patch ignores tpm_get_random() errors in
> > > > init_digests() and returns -EFAULT in pcrlock() if the TPM didn't return
> > > > random data.
> > > > 
> > > > Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
> > > 
> > > The code changes look correct to me.
> > > 
> > >    Reviewed-by: Tyler Hicks <tyhicks@canonical.com>
> > > 
> > > For whoever takes this patch through their tree, I think that adding the
> > > following Fixes tag would be useful (as well as cc'ing stable):
> > > 
> > >    Fixes: 240730437deb ("KEYS: trusted: explicitly use tpm_chip
> > > structure...")
> > > 
> > > I think it is also worth leaving a short note, in the commit message,
> > > for backporters that commit 782779b60faa ("tpm: Actually fail on TPM
> > > errors during "get random"") should be included with any backports of
> > > this patch.
> > 
> > Right, thanks. I wait for Jarkko's comments and I add both the Fixes tag
> > and the short note in the next version of the patch.
> 
> Uhm, I was thinking that maybe it is not necessary to mention commit
> 782779b60faa. This patch would still return 0 even if that commit is not
> backported (TPM_ERR_DISABLED < TPM_MAX_DIGEST_SIZE).

The commit message for 782779b60faa shows 379 being returned when
attempting to get random:

  [   18.092103] tpm tpm0: A TPM error (379) occurred attempting get random

I don't know enough about TPM chips to know how common that is...

Tyler

> 
> Roberto
> 
> -- 
> HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
> Managing Director: Li Peng, Li Jian, Shi Yanli

  reply	other threads:[~2019-08-02 16:15 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-02 15:07 [PATCH v2] KEYS: trusted: allow module init if TPM is inactive or deactivated Roberto Sassu
2019-08-02 15:07 ` Roberto Sassu
2019-08-02 15:30 ` Tyler Hicks
2019-08-02 15:30   ` Tyler Hicks
2019-08-02 15:34   ` Roberto Sassu
2019-08-02 15:34     ` Roberto Sassu
2019-08-02 16:11     ` Roberto Sassu
2019-08-02 16:11       ` Roberto Sassu
2019-08-02 16:15       ` Tyler Hicks [this message]
2019-08-02 16:15         ` Tyler Hicks

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=20190802161527.GC26616@elm \
    --to=tyhicks@canonical.com \
    --cc=crazyt2019+lml@gmail.com \
    --cc=jarkko.sakkinen@linux.intel.com \
    --cc=jejb@linux.ibm.com \
    --cc=jgg@ziepe.ca \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=nayna@linux.vnet.ibm.com \
    --cc=roberto.sassu@huawei.com \
    --cc=silviu.vlasceanu@huawei.com \
    --cc=zohar@linux.ibm.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.