All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tyler Hicks <tyhicks@canonical.com>
To: Mimi Zohar <zohar@linux.ibm.com>,
	Roberto Sassu <roberto.sassu@huawei.com>
Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
	James Bottomley <jejb@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] KEYS: trusted: allow module init if TPM is inactive or deactivated
Date: Fri, 02 Aug 2019 21:18:43 +0000	[thread overview]
Message-ID: <20190802211843.GH26616@elm> (raw)
In-Reply-To: <1562689905.28089.52.camel@linux.ibm.com>

On 2019-07-09 12:31:45, Mimi Zohar wrote:
> On Tue, 2019-07-09 at 19:24 +0300, Jarkko Sakkinen wrote:
> > On Mon, Jul 08, 2019 at 01:34:59PM -0700, James Bottomley wrote:
> > > Not a criticism of your patch, but can we please stop doing this. 
> > > Single random number sources are horrendously bad practice because it
> > > gives an attacker a single target to subvert.  We should ensure the TPM
> > > is plugged into the kernel RNG as a source and then take randomness
> > > from the mixed pool so it's harder for an attacker because they have to
> > > subvert all our sources to predict what came out.
> > 
> > It is and I agree.
> 
> I still haven't quite figured out why the digests need to be
> initialized to anything other than 0.

After looking into 0b6cf6b97b7ef1fa3c7fefab0cac897a1c4a3400, I have to
agree. I don't see the purpose of using tpm_get_random() in
init_digests().

Roberto, why can't we just initialize the digests with zeroes? It would
fix the bug for eCryptfs and NVDIMM and address the concern that James
had regarding the single random number source.

Tyler

WARNING: multiple messages have this Message-ID (diff)
From: Tyler Hicks <tyhicks@canonical.com>
To: Mimi Zohar <zohar@linux.ibm.com>,
	Roberto Sassu <roberto.sassu@huawei.com>
Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
	James Bottomley <jejb@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] KEYS: trusted: allow module init if TPM is inactive or deactivated
Date: Fri, 2 Aug 2019 16:18:43 -0500	[thread overview]
Message-ID: <20190802211843.GH26616@elm> (raw)
In-Reply-To: <1562689905.28089.52.camel@linux.ibm.com>

On 2019-07-09 12:31:45, Mimi Zohar wrote:
> On Tue, 2019-07-09 at 19:24 +0300, Jarkko Sakkinen wrote:
> > On Mon, Jul 08, 2019 at 01:34:59PM -0700, James Bottomley wrote:
> > > Not a criticism of your patch, but can we please stop doing this. 
> > > Single random number sources are horrendously bad practice because it
> > > gives an attacker a single target to subvert.  We should ensure the TPM
> > > is plugged into the kernel RNG as a source and then take randomness
> > > from the mixed pool so it's harder for an attacker because they have to
> > > subvert all our sources to predict what came out.
> > 
> > It is and I agree.
> 
> I still haven't quite figured out why the digests need to be
> initialized to anything other than 0.

After looking into 0b6cf6b97b7ef1fa3c7fefab0cac897a1c4a3400, I have to
agree. I don't see the purpose of using tpm_get_random() in
init_digests().

Roberto, why can't we just initialize the digests with zeroes? It would
fix the bug for eCryptfs and NVDIMM and address the concern that James
had regarding the single random number source.

Tyler

  reply	other threads:[~2019-08-02 21:18 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-05 16:37 [PATCH] KEYS: trusted: allow module init if TPM is inactive or deactivated Roberto Sassu
2019-07-05 16:37 ` Roberto Sassu
2019-07-08 19:55 ` Tyler Hicks
2019-07-08 19:55   ` Tyler Hicks
2019-07-08 20:34 ` James Bottomley
2019-07-08 20:34   ` James Bottomley
2019-07-09 16:24   ` Jarkko Sakkinen
2019-07-09 16:24     ` Jarkko Sakkinen
2019-07-09 16:31     ` Mimi Zohar
2019-07-09 16:31       ` Mimi Zohar
2019-08-02 21:18       ` Tyler Hicks [this message]
2019-08-02 21:18         ` Tyler Hicks
2019-07-11 19:48 ` Jarkko Sakkinen
2019-07-11 19:48   ` Jarkko Sakkinen
2019-07-15 16:44   ` Roberto Sassu
2019-07-15 16:44     ` Roberto Sassu
2019-08-01 16:32     ` Jarkko Sakkinen
2019-08-01 16:32       ` Jarkko Sakkinen
2019-08-02  8:21       ` Roberto Sassu
2019-08-02  8:21         ` Roberto Sassu
2019-08-02 14:27         ` Tyler Hicks
2019-08-02 14:27           ` Tyler Hicks
2019-08-02 19:42           ` Jarkko Sakkinen
2019-08-02 19:42             ` Jarkko Sakkinen
2019-08-02 20:23             ` Tyler Hicks
2019-08-02 20:23               ` Tyler Hicks
2019-08-02 20:35               ` Tyler Hicks
2019-08-02 20:35                 ` Tyler Hicks
2019-08-03 14:44               ` Jarkko Sakkinen
2019-08-03 14:44                 ` Jarkko Sakkinen
2019-08-04  1:46                 ` Mimi Zohar
2019-08-04  1:46                   ` Mimi Zohar
2019-08-05 14:50               ` Roberto Sassu
2019-08-05 14:50                 ` Roberto Sassu
2019-08-05 15:54                 ` Mimi Zohar
2019-08-05 15:54                   ` Mimi Zohar
2019-08-05 16:04                   ` Roberto Sassu
2019-08-05 16:04                     ` Roberto Sassu
2019-08-05 16:04                   ` Tyler Hicks
2019-08-05 16:04                     ` Tyler Hicks
2019-08-05 16:51                     ` Roberto Sassu
2019-08-05 16:51                       ` Roberto Sassu
2019-08-05 16:53                       ` Tyler Hicks
2019-08-05 16:53                         ` Tyler Hicks
2019-08-05 22:11                 ` Jarkko Sakkinen
2019-08-05 22:11                   ` Jarkko Sakkinen
2019-08-02 19:40         ` Jarkko Sakkinen
2019-08-02 19:40           ` Jarkko Sakkinen

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=20190802211843.GH26616@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.