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

[Jarkko Sakkinen]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/