Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1641559 > unrolled thread
| Started by | Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> |
|---|---|
| First post | 2017-05-15 13:20 +0200 |
| Last post | 2017-05-24 22:30 +0200 |
| Articles | 6 — 2 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH v2 2/5] tpm: introduce tpm_pcr_algo_to_crypto() and tpm_pcr_algo_from_crypto() Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> - 2017-05-15 13:20 +0200
Re: [PATCH v2 2/5] tpm: introduce tpm_pcr_algo_to_crypto() and tpm_pcr_algo_from_crypto() Roberto Sassu <roberto.sassu@huawei.com> - 2017-05-15 16:30 +0200
Re: [PATCH v2 2/5] tpm: introduce tpm_pcr_algo_to_crypto() and tpm_pcr_algo_from_crypto() Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> - 2017-05-20 15:30 +0200
Re: [PATCH v2 2/5] tpm: introduce tpm_pcr_algo_to_crypto() and tpm_pcr_algo_from_crypto() Roberto Sassu <roberto.sassu@huawei.com> - 2017-05-22 09:30 +0200
Re: [PATCH v2 2/5] tpm: introduce tpm_pcr_algo_to_crypto() and tpm_pcr_algo_from_crypto() Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> - 2017-05-24 19:40 +0200
Re: [PATCH v2 2/5] tpm: introduce tpm_pcr_algo_to_crypto() and tpm_pcr_algo_from_crypto() Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> - 2017-05-24 22:30 +0200
| From | Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> |
|---|---|
| Date | 2017-05-15 13:20 +0200 |
| Subject | Re: [PATCH v2 2/5] tpm: introduce tpm_pcr_algo_to_crypto() and tpm_pcr_algo_from_crypto() |
| Message-ID | <tHmcG-7ob-21@gated-at.bofh.it> |
On Fri, May 05, 2017 at 04:21:49PM +0200, Roberto Sassu wrote: > tpm_pcr_algorithms() returns to its callers the IDs of the hash algorithms > supported by the TPM. This patch introduces tpm_pcr_algo_to_crypto(), > so that the callers can use the crypto subsystem to calculate the digest > to be passed to tpm_pcr_extend(). > > tpm_pcr_algo_from_crypto(), implemented for completeness, is instead used What do you mean by completeness? Please, never add unused stuff. > by tpm2_seal_trusted() to perform the opposite conversion. > > Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com> > --- > v2 > > - fixed return values of tpm2_pcr_algo_to_crypto() and > tpm2_pcr_algo_from_crypto() if TPM support is disabled in the kernel Change Log only to the cover letter. > drivers/char/tpm/tpm-interface.c | 51 ++++++++++++++++++++++++++++++++++++++++ > drivers/char/tpm/tpm2-cmd.c | 42 +++++++++------------------------ > include/linux/tpm.h | 13 ++++++++++ > 3 files changed, 75 insertions(+), 31 deletions(-) This commit is just deadly wrong in so many ways. I would suggest to make extend always just take crypto ID in so you don't have to add these bizarre conversion functions. This probably covers all the patches but just "unsigned int" as type for parameters and local variables. I think I'll pass rest of the patches for now because just reviewing the two first took too much time and wait for an updated version. /Jarkko
[toc] | [next] | [standalone]
| From | Roberto Sassu <roberto.sassu@huawei.com> |
|---|---|
| Date | 2017-05-15 16:30 +0200 |
| Message-ID | <tHpay-Ra-21@gated-at.bofh.it> |
| In reply to | #1641559 |
On 5/15/2017 1:16 PM, Jarkko Sakkinen wrote: > On Fri, May 05, 2017 at 04:21:49PM +0200, Roberto Sassu wrote: >> tpm_pcr_algorithms() returns to its callers the IDs of the hash algorithms >> supported by the TPM. This patch introduces tpm_pcr_algo_to_crypto(), >> so that the callers can use the crypto subsystem to calculate the digest >> to be passed to tpm_pcr_extend(). >> >> tpm_pcr_algo_from_crypto(), implemented for completeness, is instead used > > What do you mean by completeness? Please, never add unused stuff. > >> by tpm2_seal_trusted() to perform the opposite conversion. >> >> Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com> >> --- >> v2 >> >> - fixed return values of tpm2_pcr_algo_to_crypto() and >> tpm2_pcr_algo_from_crypto() if TPM support is disabled in the kernel > > Change Log only to the cover letter. > >> drivers/char/tpm/tpm-interface.c | 51 ++++++++++++++++++++++++++++++++++++++++ >> drivers/char/tpm/tpm2-cmd.c | 42 +++++++++------------------------ >> include/linux/tpm.h | 13 ++++++++++ >> 3 files changed, 75 insertions(+), 31 deletions(-) > > This commit is just deadly wrong in so many ways. > > I would suggest to make extend always just take crypto ID in so you > don't have to add these bizarre conversion functions. The reason of this choice (as I explained in the cover letter) is that TPM users might want to produce an event log with the TCG format (which includes the TPM algorithm ID). Also, TPM IDs should be preferred because, with them, TPM users can calculate a digest directly with the TPM. Taking crypto IDs means relying on the fact that there is always a mapping between TPM IDs and crypto IDs. Otherwise, tpm_pcr_algorithms() cannot return the algorithms to its callers and PCRs cannot be extended. If TPM IDs are used, TPM users have two alternatives: calculate the digest with the TPM, or pass a SHA1 digest to tpm_pcr_extend(), so that it can be padded to extend remanining PCR banks. However, this second option will work only when the TPM driver determines the size of an algorithm without relying on the crypto subsystem. At the moment, if a TPM ID is not mapped to a crypto ID, tpm2_pcr_extend() ignores the digest. Roberto
[toc] | [prev] | [next] | [standalone]
| From | Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> |
|---|---|
| Date | 2017-05-20 15:30 +0200 |
| Message-ID | <tJcCe-20L-13@gated-at.bofh.it> |
| In reply to | #1641743 |
On Mon, May 15, 2017 at 04:22:22PM +0200, Roberto Sassu wrote: > On 5/15/2017 1:16 PM, Jarkko Sakkinen wrote: > > On Fri, May 05, 2017 at 04:21:49PM +0200, Roberto Sassu wrote: > > > tpm_pcr_algorithms() returns to its callers the IDs of the hash algorithms > > > supported by the TPM. This patch introduces tpm_pcr_algo_to_crypto(), > > > so that the callers can use the crypto subsystem to calculate the digest > > > to be passed to tpm_pcr_extend(). > > > > > > tpm_pcr_algo_from_crypto(), implemented for completeness, is instead used > > > > What do you mean by completeness? Please, never add unused stuff. > > > > > by tpm2_seal_trusted() to perform the opposite conversion. > > > > > > Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com> > > > --- > > > v2 > > > > > > - fixed return values of tpm2_pcr_algo_to_crypto() and > > > tpm2_pcr_algo_from_crypto() if TPM support is disabled in the kernel > > > > Change Log only to the cover letter. > > > > > drivers/char/tpm/tpm-interface.c | 51 ++++++++++++++++++++++++++++++++++++++++ > > > drivers/char/tpm/tpm2-cmd.c | 42 +++++++++------------------------ > > > include/linux/tpm.h | 13 ++++++++++ > > > 3 files changed, 75 insertions(+), 31 deletions(-) > > > > This commit is just deadly wrong in so many ways. > > > > I would suggest to make extend always just take crypto ID in so you > > don't have to add these bizarre conversion functions. > > The reason of this choice (as I explained in the cover letter) > is that TPM users might want to produce an event log with > the TCG format (which includes the TPM algorithm ID). Also, > TPM IDs should be preferred because, with them, TPM users > can calculate a digest directly with the TPM. > > Taking crypto IDs means relying on the fact that there > is always a mapping between TPM IDs and crypto IDs. > Otherwise, tpm_pcr_algorithms() cannot return the algorithms > to its callers and PCRs cannot be extended. If TPM IDs are used, > TPM users have two alternatives: calculate the digest with > the TPM, or pass a SHA1 digest to tpm_pcr_extend(), so that > it can be padded to extend remanining PCR banks. > > However, this second option will work only when the TPM driver > determines the size of an algorithm without relying on the crypto > subsystem. At the moment, if a TPM ID is not mapped to a crypto ID, > tpm2_pcr_extend() ignores the digest. > > Roberto What if tpm_pcr_algorithms would convert TPM IDs to crypto IDs? Externally other subsystems would have to then deal with only crypto IDs. That would favor "memcpy" (or it would become a for loop) for 1/5. /Jarkko
[toc] | [prev] | [next] | [standalone]
| From | Roberto Sassu <roberto.sassu@huawei.com> |
|---|---|
| Date | 2017-05-22 09:30 +0200 |
| Message-ID | <tJPWW-2uO-9@gated-at.bofh.it> |
| In reply to | #1646121 |
On 5/20/2017 3:22 PM, Jarkko Sakkinen wrote: > On Mon, May 15, 2017 at 04:22:22PM +0200, Roberto Sassu wrote: >> On 5/15/2017 1:16 PM, Jarkko Sakkinen wrote: >>> On Fri, May 05, 2017 at 04:21:49PM +0200, Roberto Sassu wrote: >>>> tpm_pcr_algorithms() returns to its callers the IDs of the hash algorithms >>>> supported by the TPM. This patch introduces tpm_pcr_algo_to_crypto(), >>>> so that the callers can use the crypto subsystem to calculate the digest >>>> to be passed to tpm_pcr_extend(). >>>> >>>> tpm_pcr_algo_from_crypto(), implemented for completeness, is instead used >>> >>> What do you mean by completeness? Please, never add unused stuff. >>> >>>> by tpm2_seal_trusted() to perform the opposite conversion. >>>> >>>> Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com> >>>> --- >>>> v2 >>>> >>>> - fixed return values of tpm2_pcr_algo_to_crypto() and >>>> tpm2_pcr_algo_from_crypto() if TPM support is disabled in the kernel >>> >>> Change Log only to the cover letter. >>> >>>> drivers/char/tpm/tpm-interface.c | 51 ++++++++++++++++++++++++++++++++++++++++ >>>> drivers/char/tpm/tpm2-cmd.c | 42 +++++++++------------------------ >>>> include/linux/tpm.h | 13 ++++++++++ >>>> 3 files changed, 75 insertions(+), 31 deletions(-) >>> >>> This commit is just deadly wrong in so many ways. >>> >>> I would suggest to make extend always just take crypto ID in so you >>> don't have to add these bizarre conversion functions. >> >> The reason of this choice (as I explained in the cover letter) >> is that TPM users might want to produce an event log with >> the TCG format (which includes the TPM algorithm ID). Also, >> TPM IDs should be preferred because, with them, TPM users >> can calculate a digest directly with the TPM. >> >> Taking crypto IDs means relying on the fact that there >> is always a mapping between TPM IDs and crypto IDs. >> Otherwise, tpm_pcr_algorithms() cannot return the algorithms >> to its callers and PCRs cannot be extended. If TPM IDs are used, >> TPM users have two alternatives: calculate the digest with >> the TPM, or pass a SHA1 digest to tpm_pcr_extend(), so that >> it can be padded to extend remanining PCR banks. >> >> However, this second option will work only when the TPM driver >> determines the size of an algorithm without relying on the crypto >> subsystem. At the moment, if a TPM ID is not mapped to a crypto ID, >> tpm2_pcr_extend() ignores the digest. >> >> Roberto > > What if tpm_pcr_algorithms would convert TPM IDs to crypto IDs? > > Externally other subsystems would have to then deal with only crypto > IDs. Then, other subsystems cannot: - use the TPM to calculate a digest - create an event log with the TCG format Roberto
[toc] | [prev] | [next] | [standalone]
| From | Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> |
|---|---|
| Date | 2017-05-24 19:40 +0200 |
| Message-ID | <tKIql-5iH-7@gated-at.bofh.it> |
| In reply to | #1646565 |
On Mon, May 22, 2017 at 09:21:28AM +0200, Roberto Sassu wrote: > On 5/20/2017 3:22 PM, Jarkko Sakkinen wrote: > > On Mon, May 15, 2017 at 04:22:22PM +0200, Roberto Sassu wrote: > > > On 5/15/2017 1:16 PM, Jarkko Sakkinen wrote: > > > > On Fri, May 05, 2017 at 04:21:49PM +0200, Roberto Sassu wrote: > > > > > tpm_pcr_algorithms() returns to its callers the IDs of the hash algorithms > > > > > supported by the TPM. This patch introduces tpm_pcr_algo_to_crypto(), > > > > > so that the callers can use the crypto subsystem to calculate the digest > > > > > to be passed to tpm_pcr_extend(). > > > > > > > > > > tpm_pcr_algo_from_crypto(), implemented for completeness, is instead used > > > > > > > > What do you mean by completeness? Please, never add unused stuff. > > > > > > > > > by tpm2_seal_trusted() to perform the opposite conversion. > > > > > > > > > > Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com> > > > > > --- > > > > > v2 > > > > > > > > > > - fixed return values of tpm2_pcr_algo_to_crypto() and > > > > > tpm2_pcr_algo_from_crypto() if TPM support is disabled in the kernel > > > > > > > > Change Log only to the cover letter. > > > > > > > > > drivers/char/tpm/tpm-interface.c | 51 ++++++++++++++++++++++++++++++++++++++++ > > > > > drivers/char/tpm/tpm2-cmd.c | 42 +++++++++------------------------ > > > > > include/linux/tpm.h | 13 ++++++++++ > > > > > 3 files changed, 75 insertions(+), 31 deletions(-) > > > > > > > > This commit is just deadly wrong in so many ways. > > > > > > > > I would suggest to make extend always just take crypto ID in so you > > > > don't have to add these bizarre conversion functions. > > > > > > The reason of this choice (as I explained in the cover letter) > > > is that TPM users might want to produce an event log with > > > the TCG format (which includes the TPM algorithm ID). Also, > > > TPM IDs should be preferred because, with them, TPM users > > > can calculate a digest directly with the TPM. > > > > > > Taking crypto IDs means relying on the fact that there > > > is always a mapping between TPM IDs and crypto IDs. > > > Otherwise, tpm_pcr_algorithms() cannot return the algorithms > > > to its callers and PCRs cannot be extended. If TPM IDs are used, > > > TPM users have two alternatives: calculate the digest with > > > the TPM, or pass a SHA1 digest to tpm_pcr_extend(), so that > > > it can be padded to extend remanining PCR banks. > > > > > > However, this second option will work only when the TPM driver > > > determines the size of an algorithm without relying on the crypto > > > subsystem. At the moment, if a TPM ID is not mapped to a crypto ID, > > > tpm2_pcr_extend() ignores the digest. > > > > > > Roberto > > > > What if tpm_pcr_algorithms would convert TPM IDs to crypto IDs? > > > > Externally other subsystems would have to then deal with only crypto > > IDs. > > Then, other subsystems cannot: > > - use the TPM to calculate a digest > - create an event log with the TCG format > > Roberto Can you open this up a bit? What is the use case that you canno implement? /Jarkko
[toc] | [prev] | [next] | [standalone]
| From | Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> |
|---|---|
| Date | 2017-05-24 22:30 +0200 |
| Message-ID | <tKL4S-6ZL-19@gated-at.bofh.it> |
| In reply to | #1649812 |
On Wed, May 24, 2017 at 10:33:54AM -0700, Jarkko Sakkinen wrote: > On Mon, May 22, 2017 at 09:21:28AM +0200, Roberto Sassu wrote: > > On 5/20/2017 3:22 PM, Jarkko Sakkinen wrote: > > > On Mon, May 15, 2017 at 04:22:22PM +0200, Roberto Sassu wrote: > > > > On 5/15/2017 1:16 PM, Jarkko Sakkinen wrote: > > > > > On Fri, May 05, 2017 at 04:21:49PM +0200, Roberto Sassu wrote: > > > > > > tpm_pcr_algorithms() returns to its callers the IDs of the hash algorithms > > > > > > supported by the TPM. This patch introduces tpm_pcr_algo_to_crypto(), > > > > > > so that the callers can use the crypto subsystem to calculate the digest > > > > > > to be passed to tpm_pcr_extend(). > > > > > > > > > > > > tpm_pcr_algo_from_crypto(), implemented for completeness, is instead used > > > > > > > > > > What do you mean by completeness? Please, never add unused stuff. > > > > > > > > > > > by tpm2_seal_trusted() to perform the opposite conversion. > > > > > > > > > > > > Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com> > > > > > > --- > > > > > > v2 > > > > > > > > > > > > - fixed return values of tpm2_pcr_algo_to_crypto() and > > > > > > tpm2_pcr_algo_from_crypto() if TPM support is disabled in the kernel > > > > > > > > > > Change Log only to the cover letter. > > > > > > > > > > > drivers/char/tpm/tpm-interface.c | 51 ++++++++++++++++++++++++++++++++++++++++ > > > > > > drivers/char/tpm/tpm2-cmd.c | 42 +++++++++------------------------ > > > > > > include/linux/tpm.h | 13 ++++++++++ > > > > > > 3 files changed, 75 insertions(+), 31 deletions(-) > > > > > > > > > > This commit is just deadly wrong in so many ways. > > > > > > > > > > I would suggest to make extend always just take crypto ID in so you > > > > > don't have to add these bizarre conversion functions. > > > > > > > > The reason of this choice (as I explained in the cover letter) > > > > is that TPM users might want to produce an event log with > > > > the TCG format (which includes the TPM algorithm ID). Also, > > > > TPM IDs should be preferred because, with them, TPM users > > > > can calculate a digest directly with the TPM. > > > > > > > > Taking crypto IDs means relying on the fact that there > > > > is always a mapping between TPM IDs and crypto IDs. > > > > Otherwise, tpm_pcr_algorithms() cannot return the algorithms > > > > to its callers and PCRs cannot be extended. If TPM IDs are used, > > > > TPM users have two alternatives: calculate the digest with > > > > the TPM, or pass a SHA1 digest to tpm_pcr_extend(), so that > > > > it can be padded to extend remanining PCR banks. > > > > > > > > However, this second option will work only when the TPM driver > > > > determines the size of an algorithm without relying on the crypto > > > > subsystem. At the moment, if a TPM ID is not mapped to a crypto ID, > > > > tpm2_pcr_extend() ignores the digest. > > > > > > > > Roberto > > > > > > What if tpm_pcr_algorithms would convert TPM IDs to crypto IDs? > > > > > > Externally other subsystems would have to then deal with only crypto > > > IDs. > > > > Then, other subsystems cannot: > > > > - use the TPM to calculate a digest > > - create an event log with the TCG format > > > > Roberto > > Can you open this up a bit? What is the use case that you canno > implement? > > /Jarkko The most important question is: are this used *right now*. If not, it is a definitive NAK. We don't want any future-proof code to the kernel. Always do the lowest common denominator in terms of generality and we will refactor from there when need arises. /Jarkko
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web