tpmdd-devel.lists.sourceforge.net archive mirror
 help / color / mirror / Atom feed
From: Ken Goldman <kgold@linux.vnet.ibm.com>
Cc: linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	tpmdd-devel@lists.sourceforge.net, keyrings@vger.kernel.org,
	linux-ima-devel@lists.sourceforge.net,
	Mimi Zohar <zohar@linux.vnet.ibm.com>
Subject: Re: [tpmdd-devel] [Linux-ima-devel] [PATCH v3 0/6] Updated API for TPM 2.0 PCR extend
Date: Wed, 5 Jul 2017 11:18:54 -0400	[thread overview]
Message-ID: <55cf0a07-bee8-a034-4d40-6232bc0eefb8@linux.vnet.ibm.com> (raw)
In-Reply-To: <20170628172851.fuap4ennmdj473yu@linux.intel.com>

On 6/28/2017 1:28 PM, Jarkko Sakkinen wrote:
 > On Mon, Jun 26, 2017 at 08:33:59AM -0400, Mimi Zohar wrote:
 >> 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);

This appears to be a single algorithm extend.

TPM 2.0 permits all algorithms to be extended in one operation. 
Splitting it is likely to nearly double the extend time.

Would performance be better using the TPM pattern, a count plus 
algorithm / digest pairs?  It's TPML_DIGEST_VALUES, the input to 
TPM2_PCR_Extend.

 >>>
 >>> 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).
 >
 > Doesn't this lock you to TPM?
 >
> If you seriously want to do this, I guess it is fine by me but I'm
> just wondering why the measurement list couldn't use something with
> more loose binding to TPM.
Are you asking, "Why use the TPM algorithm ID?"  If so:

1 - The IMA measurement log is already closely linked to a TPM.

2 - Why not use the TPM algorithm IDs?  They are standardized (ISO) and 
maintained.  It's unlikely that a TPM will ever be manufactured that 
uses a digest algorithm that is not in the TCG registry.

3 - The device driver needs the TPM algorithm ID already to do the 
extend, so it seems natural to use that value everywhere.

 >>> 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?

That's the question.  Why have two values and add the mapping?

 >>> 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
 >
 > There's a TPM command to query TPM algorithms.

This is true - one getcap to determine the number of algorithms, then a 
pcr read, then parse the response structures and match the algorithms to 
sizes.

Alternatively, could you create a table mapping the algorithm to the 
size?  There are currently 8 approved algorithms, meaning the table is 
32 bytes, probably less code than the queries.

As for an algorithm appearing in the TPM that's not in the table, it 
takes a year or more for a new algorithm to appear.  Is that enough time 
to patch the device driver?

FYI, the 8 algorithms are:

sha1, sha256, sha384, sha512, sm3-256, sha3-256, sha3-384, sha3-512.

I am only aware of sha1, sha256, and sm3-256 being used in production 
hardware TPMs.

  parent reply	other threads:[~2017-07-05 15:18 UTC|newest]

Thread overview: 29+ 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 ` [PATCH v3 4/6] tpm: replace TPM algorithms IDs with tpm_pcr_bank_info structs in tpm_chip Roberto Sassu
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-23 10:35   ` Jarkko Sakkinen
2017-06-21 14:29 ` [PATCH v3 6/6] tpm: pass multiple digests to tpm_pcr_extend() Roberto Sassu
     [not found]   ` <20170621142941.32674-7-roberto.sassu-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2017-06-23 10:37     ` Jarkko Sakkinen
     [not found] ` <20170621142941.32674-1-roberto.sassu-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2017-06-21 14:29   ` [PATCH v3 1/6] tpm: use tpm_buf functions to perform a PCR read Roberto Sassu
2017-06-22 10:14     ` [tpmdd-devel] " Jarkko Sakkinen
     [not found]       ` <20170622101404.blfpqcryrbe35ha4-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2017-06-22 11:54         ` Roberto Sassu
2017-06-23 10:56           ` [tpmdd-devel] " 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-23  9:55     ` [tpmdd-devel] " Jarkko Sakkinen
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-23 10:26     ` Jarkko Sakkinen
     [not found]       ` <20170623102606.3xkuqbslr3g3o22s-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2017-06-23 11:25         ` Roberto Sassu
     [not found]     ` <20170621142941.32674-4-roberto.sassu-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2017-06-27 15:24       ` Mimi Zohar
2017-06-24  9:03   ` [PATCH v3 0/6] Updated API for TPM 2.0 PCR extend Jarkko Sakkinen
     [not found]     ` <20170624090325.kbqhwkrx5qvtxveg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2017-06-26  6:58       ` Roberto Sassu
2017-06-26  7:21       ` Roberto Sassu
2017-06-28 17:10         ` Jarkko Sakkinen
2017-06-26 12:33     ` [Linux-ima-devel] " Mimi Zohar
2017-06-26 14:56       ` Roberto Sassu
2017-06-26 17:12         ` Mimi Zohar
2017-06-28 17:28       ` Jarkko Sakkinen
2017-06-28 22:28         ` Mimi Zohar
2017-07-05 15:18         ` Ken Goldman [this message]
2017-07-05 16:06           ` [tpmdd-devel] " 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=55cf0a07-bee8-a034-4d40-6232bc0eefb8@linux.vnet.ibm.com \
    --to=kgold@linux.vnet.ibm.com \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-ima-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=tpmdd-devel@lists.sourceforge.net \
    --cc=zohar@linux.vnet.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 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).