TPM trusted keys code

TPM trusted keys code

[Jarkko Sakkinen]

Hi David,

I have a proposal.

We are soon going to have the following tools for in-kernel consumers
of the TPM:

* tpm_send() that takes struct tpm_buf that gives easy tools to
  construct variable length commands. It has been already in use
  inside the TPM driver since 2015.
* tpm_find_and_get() and tpm_put() for locking the in-kernel API
  before use.
* All TPM constant values in include/linux/tpm.h

My main intention would be to refactor trusted keys code in the
following way:

1. Refactor TPM 1.x trusted keys code to use tpm_buf for constructing
   sealing messages and remove the custom stuff that you have currently.
2. Move TPM 2.x trusted keys code to security/keys/trusted

I originally implemeted TPM 2.x trusted keys code originally to the TPM
driver because the infrastructure was lacking.

My rationale here is that it is domain specific code used by only one
subsystem. For overall kernel arch it probably makes sense to have that
code located in that subsystems and have TPM driver only provide great
tools to implement that, right?

Just wanted to ask you before I start this effort. Thank you.

/Jarkko

Re: TPM trusted keys code

[David Howells]

Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> wrote:

> My rationale here is that it is domain specific code used by only one
> subsystem. For overall kernel arch it probably makes sense to have that
> code located in that subsystems and have TPM driver only provide great
> tools to implement that, right?
> 
> Just wanted to ask you before I start this effort. Thank you.

I have a partial asymmetric key subtype implementation that uses the TPM code
also - but that broken thoroughly when the tpm-2 stuff was added.  I'll have
to have another look at that (unless you want to), but it won't be till after
the next merge window.

My approach was to make a common library of routines that both the asymmetric
subtype and the trusted/encrypted types could use.

David

Re: TPM trusted keys code

[Jarkko Sakkinen]

On Thu, Oct 26, 2017 at 04:13:35PM +0100, David Howells wrote:
> Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> wrote:
> 
> > My rationale here is that it is domain specific code used by only one
> > subsystem. For overall kernel arch it probably makes sense to have that
> > code located in that subsystems and have TPM driver only provide great
> > tools to implement that, right?
> > 
> > Just wanted to ask you before I start this effort. Thank you.
> 
> I have a partial asymmetric key subtype implementation that uses the TPM code
> also - but that broken thoroughly when the tpm-2 stuff was added.  I'll have
> to have another look at that (unless you want to), but it won't be till after
> the next merge window.
> 
> My approach was to make a common library of routines that both the asymmetric
> subtype and the trusted/encrypted types could use.
> 
> David

That sounds like a awesome idea to me!

I'll continue to rework the TPM driver to the direction where you pass
struct tpm_buf to tpm_send() function instead of plain buffer.

After all the ad hoc code that trusted keys has to build TPM command
buffers can be taken away and replaced with tpm_buf helpers.

/Jarkko

Re: TPM trusted keys code

[Tudor Ambarus]

Hi, David,

On 10/26/2017 06:13 PM, David Howells wrote:
> I have a partial asymmetric key subtype implementation that uses the TPM code
> also - but that broken thoroughly when the tpm-2 stuff was added.

I would like to take a look at your implementation, if you don't mind.
Have you made it public somewhere?

Thanks,
ta

Re: TPM trusted keys code

[Jarkko Sakkinen]

On Thu, Nov 16, 2017 at 05:33:16PM +0200, Tudor Ambarus wrote:
> Hi, David,
> 
> On 10/26/2017 06:13 PM, David Howells wrote:
> > I have a partial asymmetric key subtype implementation that uses the TPM code
> > also - but that broken thoroughly when the tpm-2 stuff was added.
> 
> I would like to take a look at your implementation, if you don't mind.
> Have you made it public somewhere?
> 
> Thanks,
> ta

I'll start rework on TPM in-kernel API as soon as the SGX driver has
been upstreamed. Instead of a raw buffer you pass a struct tpm_buf
instance to tpm_send() and get also the response to that buffer.

There is a set of helpers to construct command buffers already widely
used inside the TPM driver.

I'll also move all the protocol specific constants to
include/linux/tpm.h.

/Jarkko