Re: [tpmdd-devel] [PATCH 4/4] keys, trusted: seal/unseal with TPM 2.0 chips

[Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>]

I don't mean to be impolite but could line up your replies properly
and avoid top-posting. I'd recommend 72 chars per line. Thanks.

On Mon, Oct 05, 2015 at 12:20:47PM +0000, Fuchs, Andreas wrote:
> That's why I propose to give the context-save-blob into the kernel. It
> does not require any TPM2_Load of the key-chain or TPM2_CreatePrimary
> prior to key usage.
> 
> BTW, in the current TSS2-model context-save-blobs are the preferred
> way for "moving/copying" loaded objects between two applications or
> threads. The TSS2 crew did not see any value in having a "libdrm-like"
> flink() call. Since you have to transfer the handle anyways,
> transferring those few bytes of blob are actually just as easy and
> management inside the daemon becomes way simple without flink()ing...
> ;-)
> 
> Regarding the in-kernel "minimal resource manager": AFAIK there is
> already a tpm-mutex inside the kernel. We could use that mutex and
> then have the algorithm:
>
> [SNIP]

I don't care about one purpose hacks. Second, I don't care about pseudo
code (at least not for "too big things"). It has tendency to mask
unexpected details. If you want to propose something, please go through
the patch process.

> We don't need anything more fancy than this. And it should even
> guarantee that the old values are still present after mutex_release,
> so (opposed to a full-blown resource-manager) we do not need to keep
> track and rewrite virtual handles inside the user-space commands.
> 
> IMHO, this should be lightweight enough even for the most embedded of
> applications, since the 2*2k blobs are only allocated on demand...

It's still unnecessary functionality and increases the kernel image size
and every hack requires maintenance. It would probably end up needing
compilation flag as there exists efforts like:

https://tiny.wiki.kernel.org/

My simple and stupid solution does not *prevent* adding better
synchronization. I would go with that and implement access broker
properly and not for just one use case later on.

> ChromeOS with 1.2 uses a forked patched TrouSerS, right ?
> I don't know about 2.0 though...

Yup, patched to use UDP sockets.

> Cheers,
> Andreas

/Jarkko