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

[James Bottomley]

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
overlay).

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.

James