Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1671713 > unrolled thread
| Started by | Roberto Sassu <roberto.sassu@huawei.com> |
|---|---|
| First post | 2017-06-21 16:40 +0200 |
| Last post | 2017-06-29 00:30 +0200 |
| Articles | 4 on this page of 24 — 3 participants |
Back to article view | Back to linux.kernel
[PATCH v3 0/6] Updated API for TPM 2.0 PCR extend Roberto Sassu <roberto.sassu@huawei.com> - 2017-06-21 16:40 +0200
[PATCH v3 5/6] tpm: introduce tpm_get_pcr_banks_info() Roberto Sassu <roberto.sassu@huawei.com> - 2017-06-21 16:40 +0200
Re: [PATCH v3 5/6] tpm: introduce tpm_get_pcr_banks_info() Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> - 2017-06-23 12:40 +0200
[PATCH v3 6/6] tpm: pass multiple digests to tpm_pcr_extend() Roberto Sassu <roberto.sassu@huawei.com> - 2017-06-21 16:40 +0200
Re: [tpmdd-devel] [PATCH v3 6/6] tpm: pass multiple digests to tpm_pcr_extend() Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> - 2017-06-23 12:40 +0200
[PATCH v3 1/6] tpm: use tpm_buf functions to perform a PCR read Roberto Sassu <roberto.sassu@huawei.com> - 2017-06-21 16:40 +0200
Re: [tpmdd-devel] [PATCH v3 1/6] tpm: use tpm_buf functions to perform a PCR read Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> - 2017-06-22 12:20 +0200
Re: [tpmdd-devel] [PATCH v3 1/6] tpm: use tpm_buf functions to perform a PCR read Roberto Sassu <roberto.sassu@huawei.com> - 2017-06-22 14:00 +0200
Re: [tpmdd-devel] [PATCH v3 1/6] tpm: use tpm_buf functions to perform a PCR read Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> - 2017-06-23 13:00 +0200
[PATCH v3 4/6] tpm: replace TPM algorithms IDs with tpm_pcr_bank_info structs in tpm_chip Roberto Sassu <roberto.sassu@huawei.com> - 2017-06-21 16:40 +0200
Re: [PATCH v3 4/6] tpm: replace TPM algorithms IDs with tpm_pcr_bank_info structs in tpm_chip Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> - 2017-06-23 12:40 +0200
[PATCH v3 3/6] tpm: introduce tpm_pcr_bank_info structure with digest_size from TPM Roberto Sassu <roberto.sassu@huawei.com> - 2017-06-21 16:40 +0200
Re: [PATCH v3 3/6] tpm: introduce tpm_pcr_bank_info structure with digest_size from TPM Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> - 2017-06-23 12:30 +0200
Re: [PATCH v3 3/6] tpm: introduce tpm_pcr_bank_info structure with digest_size from TPM Roberto Sassu <roberto.sassu@huawei.com> - 2017-06-23 13:30 +0200
Re: [tpmdd-devel] [PATCH v3 3/6] tpm: introduce tpm_pcr_bank_info structure with digest_size from TPM Mimi Zohar <zohar@linux.vnet.ibm.com> - 2017-06-27 17:30 +0200
Re: [PATCH v3 0/6] Updated API for TPM 2.0 PCR extend Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> - 2017-06-24 11:10 +0200
Re: [PATCH v3 0/6] Updated API for TPM 2.0 PCR extend Roberto Sassu <roberto.sassu@huawei.com> - 2017-06-26 09:00 +0200
Re: [PATCH v3 0/6] Updated API for TPM 2.0 PCR extend Roberto Sassu <roberto.sassu@huawei.com> - 2017-06-26 09:30 +0200
Re: [PATCH v3 0/6] Updated API for TPM 2.0 PCR extend Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> - 2017-06-28 20:00 +0200
Re: [Linux-ima-devel] [PATCH v3 0/6] Updated API for TPM 2.0 PCR extend Mimi Zohar <zohar@linux.vnet.ibm.com> - 2017-06-26 14:40 +0200
Re: [Linux-ima-devel] [PATCH v3 0/6] Updated API for TPM 2.0 PCR extend Roberto Sassu <roberto.sassu@huawei.com> - 2017-06-26 17:00 +0200
Re: [Linux-ima-devel] [PATCH v3 0/6] Updated API for TPM 2.0 PCR extend Mimi Zohar <zohar@linux.vnet.ibm.com> - 2017-06-26 19:20 +0200
Re: [Linux-ima-devel] [PATCH v3 0/6] Updated API for TPM 2.0 PCR extend Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> - 2017-06-28 20:00 +0200
Re: [Linux-ima-devel] [PATCH v3 0/6] Updated API for TPM 2.0 PCR extend Mimi Zohar <zohar@linux.vnet.ibm.com> - 2017-06-29 00:30 +0200
Page 2 of 2 — ← Prev page 1 [2]
| From | Roberto Sassu <roberto.sassu@huawei.com> |
|---|---|
| Date | 2017-06-26 17:00 +0200 |
| Subject | Re: [Linux-ima-devel] [PATCH v3 0/6] Updated API for TPM 2.0 PCR extend |
| Message-ID | <tWDED-3EY-41@gated-at.bofh.it> |
| In reply to | #1674725 |
On 6/26/2017 2:33 PM, 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); >> >> 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. This solution requires that SHA1 digests are always calculated and included in the event log, even if SHA1 has not been selected by the user. I think this is not acceptable in the scenarios where saving power and memory is important. I would instead use the first digest passed to tpm_pcr_extend() (it must be the first also in the event log) to extend banks for which the digest is missing. If TPM users want to pad/truncate a different digest, they can pass to tpm_pcr_extend() a digest for each TPM algorithm. This is possible with the patches I sent because TPM users receive the TPM algorithm IDs and the digest size for each algorithm. Regarding the possibility that SHA1 could not be supported, for now this shouldn't happen because, according to TCG, SHA1 support is mandatory for TPM 2.0: https://trustedcomputinggroup.org/wp-content/uploads/TCG_Algorithm_Registry_Rev_1.24.pdf I don't know if SHA1 can be marked as Legacy in a next revision of the document. Roberto >> 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 >> > -- HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Bo PENG, Qiuen PENG, Shengli WANG
[toc] | [prev] | [next] | [standalone]
| From | Mimi Zohar <zohar@linux.vnet.ibm.com> |
|---|---|
| Date | 2017-06-26 19:20 +0200 |
| Subject | Re: [Linux-ima-devel] [PATCH v3 0/6] Updated API for TPM 2.0 PCR extend |
| Message-ID | <tWFQ6-5au-21@gated-at.bofh.it> |
| In reply to | #1674849 |
On Mon, 2017-06-26 at 16:56 +0200, Roberto Sassu wrote: > On 6/26/2017 2:33 PM, 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); > >> > >> 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. > > This solution requires that SHA1 digests are always calculated > and included in the event log, even if SHA1 has not been selected > by the user. I think this is not acceptable in the scenarios where > saving power and memory is important. > > I would instead use the first digest passed to tpm_pcr_extend() > (it must be the first also in the event log) to extend banks > for which the digest is missing. As long as we don't break the existing userspace/kernel IMA measurement list ABI, then I'm Ok with this. Mimi > If TPM users want to pad/truncate a different digest, they can > pass to tpm_pcr_extend() a digest for each TPM algorithm. > This is possible with the patches I sent because TPM users > receive the TPM algorithm IDs and the digest size for each > algorithm. > > Regarding the possibility that SHA1 could not be supported, > for now this shouldn't happen because, according to TCG, > SHA1 support is mandatory for TPM 2.0: > > https://trustedcomputinggroup.org/wp-content/uploads/TCG_Algorithm_Registry_Rev_1.24.pdf > > I don't know if SHA1 can be marked as Legacy in a next > revision of the document. > > Roberto > > > >> 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 > >> > > >
[toc] | [prev] | [next] | [standalone]
| From | Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> |
|---|---|
| Date | 2017-06-28 20:00 +0200 |
| Subject | Re: [Linux-ima-devel] [PATCH v3 0/6] Updated API for TPM 2.0 PCR extend |
| Message-ID | <tXppV-t5-21@gated-at.bofh.it> |
| In reply to | #1674725 |
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); > > > > 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. > > 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. Why doesn't it work to pick algorithm X from the availabe options and do truncation/padding for that? Not necessarily 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 There's a TPM command to query TPM algorithms. /Jarkko
[toc] | [prev] | [next] | [standalone]
| From | Mimi Zohar <zohar@linux.vnet.ibm.com> |
|---|---|
| Date | 2017-06-29 00:30 +0200 |
| Subject | Re: [Linux-ima-devel] [PATCH v3 0/6] Updated API for TPM 2.0 PCR extend |
| Message-ID | <tXtDc-13b-23@gated-at.bofh.it> |
| In reply to | #1676912 |
On Wed, 2017-06-28 at 20:28 +0300, 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); > > > > > > 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. I expect Ken will comment ... > > > 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. > > Why doesn't it work to pick algorithm X from the availabe options and > do truncation/padding for that? Not necessarily SHA1. Yes, it does work, as Roberto pointed out in a subsequent post. For TPM 2.0 the first digest algorithm in the IMA hash agile crypto header, will be used as the default digest used for truncating/padding the other unspecified banks. In order not to break the existing userspace ABI, we will still need to support the existing SHA1 based IMA securityfs measurement lists, whether or not SHA1 is included in the hash agile IMA securityfs measurement lists. > > > > > 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. > > > > There's a TPM command to query TPM algorithms. Right, tpm2_init_pcr_bank_info(), defined in Roberto's patch "tpm: introduce tpm_pcr_bank_info structure with digest_size from TPM", gets the TPM digest size and stores it in the active bank structure (tpm_pcr_bank_info). Mimi
[toc] | [prev] | [standalone]
Page 2 of 2 — ← Prev page 1 [2]
Back to top | Article view | linux.kernel
csiph-web