Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1641559 > unrolled thread

Re: [PATCH v2 2/5] tpm: introduce tpm_pcr_algo_to_crypto() and tpm_pcr_algo_from_crypto()

Started byJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
First post2017-05-15 13:20 +0200
Last post2017-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.


Contents

  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

#1641559 — Re: [PATCH v2 2/5] tpm: introduce tpm_pcr_algo_to_crypto() and tpm_pcr_algo_from_crypto()

FromJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Date2017-05-15 13:20 +0200
SubjectRe: [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]


#1641743

FromRoberto Sassu <roberto.sassu@huawei.com>
Date2017-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]


#1646121

FromJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Date2017-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]


#1646565

FromRoberto Sassu <roberto.sassu@huawei.com>
Date2017-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]


#1649812

FromJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Date2017-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]


#1649931

FromJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Date2017-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