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

Groups > linux.kernel > #1245974 > unrolled thread

Re: [PATCH 3/4] tpm: seal/unseal for TPM 2.0

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 3/4] tpm: seal/unseal for TPM 2.0 Jason Gunthorpe <jgunthorpe@obsidianresearch.com> - 2015-10-13 19:40 +0200
    Re: [PATCH 3/4] tpm: seal/unseal for TPM 2.0 Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> - 2015-10-13 21:50 +0200

#1245974 — Re: [PATCH 3/4] tpm: seal/unseal for TPM 2.0

On Fri, Oct 02, 2015 at 11:38:17AM +0300, Jarkko Sakkinen wrote:
> Added tpm_trusted_seal() and tpm_trusted_unseal() API for sealing
> trusted keys.
> 
> This patch implements basic sealing and unsealing functionality for
> TPM 2.0:

We really need to stop using chip id's as a handle - the caller should
be using a pointer, it is just a horrible API, and the TPM_ANY_NUM
business is awful too.. TPM's are stateful devices!

Is it feasible to introduce new APIs with a saner scheme?

The api layering also seems really weird to me. At a minimum the
tpm_seal_trusted should be called within key_seal, but really, should
key_seal be migrated into the TPM core? I'm not sure it makes alot of
sense to have a tpm_seal_trusted which uses the high level key structs
when other tpm functions are all low level RPC wrappers...

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1246086

On Tue, Oct 13, 2015 at 11:34:42AM -0600, Jason Gunthorpe wrote:
> On Fri, Oct 02, 2015 at 11:38:17AM +0300, Jarkko Sakkinen wrote:
> > Added tpm_trusted_seal() and tpm_trusted_unseal() API for sealing
> > trusted keys.
> > 
> > This patch implements basic sealing and unsealing functionality for
> > TPM 2.0:
> 
> We really need to stop using chip id's as a handle - the caller should
> be using a pointer, it is just a horrible API, and the TPM_ANY_NUM
> business is awful too.. TPM's are stateful devices!

Eventually this needs to be refactored out. I don't see it in the scope
of these patches or as high priority ATM.

> Is it feasible to introduce new APIs with a saner scheme?
> 
> The api layering also seems really weird to me. At a minimum the
> tpm_seal_trusted should be called within key_seal, but really, should
> key_seal be migrated into the TPM core? I'm not sure it makes alot of
> sense to have a tpm_seal_trusted which uses the high level key structs
> when other tpm functions are all low level RPC wrappers...

I think tpm_seal() inside trusted.c is not a very good API. It takes the
ad hoc version of the structs given to key_seal from stack. I don't see
a problem here.

My viewpoint has been that key_seal/unseal in trusted.c should be
refactored out and TPM1 implementations seal/unseal should be moved to
the TPM subsystem. There's so little amount of in-kernel low-level TPM
code that IMHO it makes sense to keep in one place (as are all the other
TPM utility functions).

I can work on the TPM1 migration when we have the basic TPM2 stuff in
place.

> Jason

/Jakrkko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web