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