Re: [tpmdd-devel] [RFC] tpm2-space: add handling for global session exhaustion

From: James Bottomley
Date: Thu Feb 09 2017 - 15:14:10 EST

On Thu, 2017-02-09 at 03:06 -0600, Dr. Greg Wettstein wrote:
> On Jan 30, 11:58pm, Jarkko Sakkinen wrote:
> } Subject: Re: [tpmdd-devel] [RFC] tpm2-space: add handling for
> global sessi
> Good morning, I hope the day is going well for everyone.
> > I'm kind dilating to an opinion that we would leave this commit out
> > from the first kernel release that will contain the resource
> > manager with similar rationale as Jason gave me for whitelisting:
> > get the basic stuff in and once it is used with some workloads
> > whitelisting and exhaustion will take eventually the right form.
> >
> > How would you feel about this?
> I wasn't able to locate the exact context to include but we noted
> with interest Ken's comments about his need to support a model where
> a client needs a TPM session for transaction purposes which can last
> a highly variable amount of time. That and concerns about command
> white-listing, hardware denial of service and related issues tend to
> underscore our concerns about how much TPM resource management should
> go into the kernel.
> Once an API is in the kernel we live with it forever.

This actually is far too strong a statement: Once you make API
guarantees, you have to live with them forever, but there's a
considerable difference between an API guarantee and the API itself.
For instance the kernel overlay filesystem has gone through several
iterations of file whiteouts (showing a file as deleted above a read
only copy): we began with an inode flag, moved to an extended attribute
and finally ended up with a device. Each of those three changes was
fairly radical to the VFS API, but didn't fundamentally alter the API
guarantee (that users wouldn't see a file after it was deleted on an

The API guarantee /dev/tpms0 is adding is that you won't see TPM out of
memory errors based on what other people are doing, so I think it's a
simple isolation guarantee we can live with long term. I think that's
a solidly defensible one.

However, right at the moment the guarantee isn't that you won't be
affcted by *anything* another user does, so it's a weak guarantee: you
will see uncorrectable regapping errors based on what others are doing
and you will see global session exhaustion.

I think we begin with the defensible weak guarantee and discuss how to
strengthen it.