All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: linux-security-module@vger.kernel.org
Subject: Re: [Linux-ima-devel] [PATCH v3 0/6] Updated API for TPM 2.0 PCR extend
Date: Mon, 26 Jun 2017 12:33:59 +0000	[thread overview]
Message-ID: <1498480439.3387.45.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <20170624090325.kbqhwkrx5qvtxveg@linux.intel.com>

On Sat, 2017-06-24 at 11:03 +0200, Jarkko Sakkinen wrote:
> On Wed, Jun 21, 2017 at 04:29:35PM +0200, Roberto Sassu wrote:


> To move this forward and be more constructive here's how I see it
> should be done (along the lines, draft):
> 
> int tpm_pcr_extend(u32 chip_num, int pcr_idx, unsigned int alg,
> 		   const u8 *hash);
> 
> The paramater 'alg' is crypto ID as specified by crypto subsystem.

Based on Kenneth Goldman's input, the new IMA TPM-2.0 crypto hash
agile measurement list will contain the TPM crypto hash algorithm ids
(TPM crypto-ID). 

> TPM driver must have a precompiled table of mappings for crypto IDs
> and TPM algorithm IDs.

We could map the TPM crypto-IDs to the crypto subsystem IDs and then
map them back, but is that necessary?

> 
> In addition it must have dynamically acquired list of TPM alg IDs.
> For those algs that static mapping does not exist it must extend
> them like we do now everything else except SHA-1 (Naynas changes).

Padding/truncating an unknown bank using SHA1 is fine, but at some
point, as Roberto pointed out to me, TPM 2.0's might not support SHA-
1.  So for the record, we're hard coding the use of SHA1 for the
unknown algorithms whether or not the TPM supports SHA1.

> There's absolutely no need to pass digest size like you do BTW as it is
> defined by the standard.

For algorithms known to the crypto subsystem, that is fine, but for
the unknown TPM crypto algorithms, we would need to somehow query the
TPM for the digest sizes to create the mapping.

Mimi

> I also except that where ever this interleaves with trusted keys there
> won't be duplicate structures and code.
> 
> /Jarkko
> 


WARNING: multiple messages have this Message-ID (diff)
From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
	Roberto Sassu <roberto.sassu@huawei.com>
Cc: linux-ima-devel@lists.sourceforge.net,
	linux-security-module@vger.kernel.org,
	tpmdd-devel@lists.sourceforge.net, keyrings@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Kenneth Goldman <kgoldman@us.ibm.com>
Subject: Re: [Linux-ima-devel] [PATCH v3 0/6] Updated API for TPM 2.0 PCR extend
Date: Mon, 26 Jun 2017 08:33:59 -0400	[thread overview]
Message-ID: <1498480439.3387.45.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <20170624090325.kbqhwkrx5qvtxveg@linux.intel.com>

On Sat, 2017-06-24 at 11:03 +0200, Jarkko Sakkinen wrote:
> On Wed, Jun 21, 2017 at 04:29:35PM +0200, Roberto Sassu wrote:


> To move this forward and be more constructive here's how I see it
> should be done (along the lines, draft):
> 
> int tpm_pcr_extend(u32 chip_num, int pcr_idx, unsigned int alg,
> 		   const u8 *hash);
> 
> The paramater 'alg' is crypto ID as specified by crypto subsystem.

Based on Kenneth Goldman's input, the new IMA TPM-2.0 crypto hash
agile measurement list will contain the TPM crypto hash algorithm ids
(TPM crypto-ID). 

> TPM driver must have a precompiled table of mappings for crypto IDs
> and TPM algorithm IDs.

We could map the TPM crypto-IDs to the crypto subsystem IDs and then
map them back, but is that necessary?

> 
> In addition it must have dynamically acquired list of TPM alg IDs.
> For those algs that static mapping does not exist it must extend
> them like we do now everything else except SHA-1 (Naynas changes).

Padding/truncating an unknown bank using SHA1 is fine, but at some
point, as Roberto pointed out to me, TPM 2.0's might not support SHA-
1.  So for the record, we're hard coding the use of SHA1 for the
unknown algorithms whether or not the TPM supports SHA1.

> There's absolutely no need to pass digest size like you do BTW as it is
> defined by the standard.

For algorithms known to the crypto subsystem, that is fine, but for
the unknown TPM crypto algorithms, we would need to somehow query the
TPM for the digest sizes to create the mapping.

Mimi

> I also except that where ever this interleaves with trusted keys there
> won't be duplicate structures and code.
> 
> /Jarkko
> 

WARNING: multiple messages have this Message-ID (diff)
From: zohar@linux.vnet.ibm.com (Mimi Zohar)
To: linux-security-module@vger.kernel.org
Subject: [Linux-ima-devel] [PATCH v3 0/6] Updated API for TPM 2.0 PCR extend
Date: Mon, 26 Jun 2017 08:33:59 -0400	[thread overview]
Message-ID: <1498480439.3387.45.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <20170624090325.kbqhwkrx5qvtxveg@linux.intel.com>

On Sat, 2017-06-24 at 11:03 +0200, Jarkko Sakkinen wrote:
> On Wed, Jun 21, 2017 at 04:29:35PM +0200, Roberto Sassu wrote:


> To move this forward and be more constructive here's how I see it
> should be done (along the lines, draft):
> 
> int tpm_pcr_extend(u32 chip_num, int pcr_idx, unsigned int alg,
> 		   const u8 *hash);
> 
> The paramater 'alg' is crypto ID as specified by crypto subsystem.

Based on Kenneth Goldman's input, the new IMA TPM-2.0 crypto hash
agile measurement list will contain the TPM crypto hash algorithm ids
(TPM crypto-ID).?

> TPM driver must have a precompiled table of mappings for crypto IDs
> and TPM algorithm IDs.

We could map the TPM crypto-IDs to the crypto subsystem IDs and then
map them back, but is that necessary?

> 
> In addition it must have dynamically acquired list of TPM alg IDs.
> For those algs that static mapping does not exist it must extend
> them like we do now everything else except SHA-1 (Naynas changes).

Padding/truncating an unknown bank using SHA1 is fine, but at some
point, as Roberto pointed out to me, TPM 2.0's might not support SHA-
1. ?So for the record, we're hard coding the use of SHA1 for the
unknown algorithms whether or not the TPM supports SHA1.

> There's absolutely no need to pass digest size like you do BTW as it is
> defined by the standard.

For algorithms known to the crypto subsystem, that is fine, but for
the unknown TPM crypto algorithms, we would need to somehow query the
TPM for the digest sizes to create the mapping.

Mimi

> I also except that where ever this interleaves with trusted keys there
> won't be duplicate structures and code.
> 
> /Jarkko
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2017-06-26 12:33 UTC|newest]

Thread overview: 104+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-21 14:29 [PATCH v3 0/6] Updated API for TPM 2.0 PCR extend Roberto Sassu
2017-06-21 14:29 ` Roberto Sassu
2017-06-21 14:29 ` Roberto Sassu
2017-06-21 14:29 ` Roberto Sassu
2017-06-21 14:29 ` [PATCH v3 1/6] tpm: use tpm_buf functions to perform a PCR read Roberto Sassu
2017-06-21 14:29   ` Roberto Sassu
2017-06-21 14:29   ` Roberto Sassu
2017-06-21 14:29   ` Roberto Sassu
2017-06-22 10:14   ` [tpmdd-devel] " Jarkko Sakkinen
2017-06-22 10:14     ` Jarkko Sakkinen
2017-06-22 10:14     ` Jarkko Sakkinen
2017-06-22 11:54     ` Roberto Sassu
2017-06-22 11:54       ` Roberto Sassu
2017-06-22 11:54       ` [tpmdd-devel] " Roberto Sassu
2017-06-22 11:54       ` Roberto Sassu
2017-06-23 10:56       ` Jarkko Sakkinen
2017-06-23 10:56         ` Jarkko Sakkinen
2017-06-23 10:56         ` Jarkko Sakkinen
2017-06-21 14:29 ` [PATCH v3 2/6] tpm: use tpm2_pcr_read_tpm_buf() in tpm2_do_selftest() Roberto Sassu
2017-06-21 14:29   ` Roberto Sassu
2017-06-21 14:29   ` Roberto Sassu
2017-06-21 14:29   ` Roberto Sassu
2017-06-23  9:55   ` [tpmdd-devel] " Jarkko Sakkinen
2017-06-23  9:55     ` Jarkko Sakkinen
2017-06-23  9:55     ` Jarkko Sakkinen
2017-06-23 10:22     ` Roberto Sassu
2017-06-23 10:22       ` Roberto Sassu
2017-06-23 10:22       ` Roberto Sassu
2017-06-23 10:22       ` Roberto Sassu
2017-06-21 14:29 ` [PATCH v3 3/6] tpm: introduce tpm_pcr_bank_info structure with digest_size from TPM Roberto Sassu
2017-06-21 14:29   ` Roberto Sassu
2017-06-21 14:29   ` Roberto Sassu
2017-06-21 14:29   ` Roberto Sassu
2017-06-23 10:26   ` Jarkko Sakkinen
2017-06-23 10:26     ` Jarkko Sakkinen
2017-06-23 10:26     ` Jarkko Sakkinen
2017-06-23 11:25     ` Roberto Sassu
2017-06-23 11:25       ` Roberto Sassu
2017-06-23 11:25       ` Roberto Sassu
2017-06-23 11:25       ` Roberto Sassu
2017-06-27 15:24   ` [tpmdd-devel] [PATCH v3 3/6] tpm: introduce tpm_pcr_bank_info structure with digest_size from TP Mimi Zohar
2017-06-27 15:24     ` [PATCH v3 3/6] tpm: introduce tpm_pcr_bank_info structure with digest_size from TPM Mimi Zohar
2017-06-27 15:24     ` [tpmdd-devel] " Mimi Zohar
2017-06-27 15:24     ` Mimi Zohar
2017-06-21 14:29 ` [PATCH v3 4/6] tpm: replace TPM algorithms IDs with tpm_pcr_bank_info structs in tpm_chip Roberto Sassu
2017-06-21 14:29   ` Roberto Sassu
2017-06-21 14:29   ` Roberto Sassu
2017-06-21 14:29   ` Roberto Sassu
2017-06-23 10:32   ` Jarkko Sakkinen
2017-06-23 10:32     ` Jarkko Sakkinen
2017-06-23 10:32     ` Jarkko Sakkinen
2017-06-21 14:29 ` [PATCH v3 5/6] tpm: introduce tpm_get_pcr_banks_info() Roberto Sassu
2017-06-21 14:29   ` Roberto Sassu
2017-06-21 14:29   ` Roberto Sassu
2017-06-21 14:29   ` Roberto Sassu
2017-06-23 10:35   ` Jarkko Sakkinen
2017-06-23 10:35     ` Jarkko Sakkinen
2017-06-23 10:35     ` Jarkko Sakkinen
2017-06-21 14:29 ` [PATCH v3 6/6] tpm: pass multiple digests to tpm_pcr_extend() Roberto Sassu
2017-06-21 14:29   ` Roberto Sassu
2017-06-21 14:29   ` Roberto Sassu
2017-06-21 14:29   ` Roberto Sassu
2017-06-23 10:37   ` [tpmdd-devel] " Jarkko Sakkinen
2017-06-23 10:37     ` Jarkko Sakkinen
2017-06-23 10:37     ` [tpmdd-devel] " Jarkko Sakkinen
2017-06-23 10:37     ` Jarkko Sakkinen
2017-06-24  9:03 ` [PATCH v3 0/6] Updated API for TPM 2.0 PCR extend Jarkko Sakkinen
2017-06-24  9:03   ` Jarkko Sakkinen
2017-06-24  9:03   ` Jarkko Sakkinen
2017-06-24  9:03   ` Jarkko Sakkinen
2017-06-26  6:58   ` Roberto Sassu
2017-06-26  6:58     ` Roberto Sassu
2017-06-26  6:58     ` Roberto Sassu
2017-06-26  6:58     ` Roberto Sassu
2017-06-26  7:21   ` Roberto Sassu
2017-06-26  7:21     ` Roberto Sassu
2017-06-26  7:21     ` Roberto Sassu
2017-06-26  7:21     ` Roberto Sassu
2017-06-28 17:10     ` Jarkko Sakkinen
2017-06-28 17:10       ` Jarkko Sakkinen
2017-06-28 17:10       ` Jarkko Sakkinen
2017-06-26 12:33   ` Mimi Zohar [this message]
2017-06-26 12:33     ` [Linux-ima-devel] " Mimi Zohar
2017-06-26 12:33     ` Mimi Zohar
2017-06-26 14:56     ` Roberto Sassu
2017-06-26 14:56       ` Roberto Sassu
2017-06-26 14:56       ` Roberto Sassu
2017-06-26 14:56       ` Roberto Sassu
2017-06-26 17:12       ` Mimi Zohar
2017-06-26 17:12         ` Mimi Zohar
2017-06-26 17:12         ` Mimi Zohar
2017-06-28 17:28     ` Jarkko Sakkinen
2017-06-28 17:28       ` Jarkko Sakkinen
2017-06-28 17:28       ` Jarkko Sakkinen
2017-06-28 22:28       ` Mimi Zohar
2017-06-28 22:28         ` Mimi Zohar
2017-06-28 22:28         ` Mimi Zohar
2017-07-05 15:18       ` [tpmdd-devel] " Ken Goldman
2017-07-05 15:18         ` Ken Goldman
2017-07-05 15:18         ` Ken Goldman
2017-07-05 15:18         ` Ken Goldman
2017-07-05 16:06         ` Mimi Zohar
2017-07-05 16:06           ` Mimi Zohar
2017-07-05 16:06           ` 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=1498480439.3387.45.camel@linux.vnet.ibm.com \
    --to=zohar@linux.vnet.ibm.com \
    --cc=linux-security-module@vger.kernel.org \
    /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.