Re: [openssl-tpm2-engine] tpm sessions

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Mon, 2019-03-18 at 18:03 +0000, Doug Fraser wrote:
> So we have moved beyond the signaling issues on our TPM for now, but
> in ramping up performance saturation testing, I am pounding on the
> openssl engine with multiple threads of execution, and I am finding
> this fault.
> 
> /var/log/messages:Mar 18 16:43:28 C05BCB00C0A000001153 kern.err
> kernel: [11840.869864] tpm tpm0: tpm_try_transmit: tpm_send: error -5
> /var/log/messages:Mar 18 16:43:28 C05BCB00C0A000001153 kern.err
> kernel: [11840.878969] tpm tpm0: A TPM error (357) occurred flushing
> context

This sounds a bit serious.  I've taken the liberty of cc'ing the linux-
integrity group which is the mailing list where kernel based TPM issues
get discussed.  Error -5 is EIO which still points to a TPM
communications problem.

> Within the kernel, reflect up through the applications as:
> 
> TPM2_StartAuthSession failed with 2309
> TPM_RC_SESSION_HANDLES - out of session handles - a session must be
> flushed before a new session may be created
> Failed to get Key Handle in TPM EC key routines
> 
> The underlying tss code is build with:
> 
> CCFLAGS +=  -DTPM_POSIX \
>         -DTPM_INTERFACE_TYPE_DEFAULT="\"dev\""  \
>         -DTPM_DEVICE_DEFAULT="\"/dev/tpmrm0\"" \
>         $(BLD_SYSROOT)
> 
> So we should be using the tpmrm  resource manager within the kernel.

The answer should be yes because without it you'll exhaust the TPM
resources in a multi-threaded environment.  The TPM has severe limits
(like 3) on the number of keys which can be active at any given time.

What is happening in the tpmrm situation is that you get one resource
manager instance for every separate open of /dev/tpmrm0 but also every
TPM operation you try results in a resource manager context save and
load for ever volatile key handle and session ... essentially it will
be more than tripling the TPM transaction load, since the way the
openssl engine works, it usually needs the parent key, a session and
the actual key you're loading every time you do something.

once a resource manager context flush fails we actually get left with
whatever handle it was trying to flush stuck in the TPM which will lead
to resource exhaustion.

> If I run the test code as a single instance, this never occurs
> (within the bounds of 64 hours of constant running)
> 
> Is there a practical limit to the openssl engine, underlying tpmrm,
> or even the underlying physical block that I am ignoring here?
> My view was that as long as you pass through the tpmrm, you might
> stall, but the resources would be managed.

Right, the resource manager is supposed to make the TPM scalable. 
There is a hard limit (64 usually) on the number of active sessions you
can have even with a resource manager, but I don't think you're hitting
that.

James

> I am going back to dig through tpm-tis, in particular, tpm2-cmd.c and
> tpm-interface.c.