From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753882AbdBIUOB (ORCPT ); Thu, 9 Feb 2017 15:14:01 -0500 Received: from bedivere.hansenpartnership.com ([66.63.167.143]:45636 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752273AbdBIUN7 (ORCPT ); Thu, 9 Feb 2017 15:13:59 -0500 Message-ID: <1486670750.2616.55.camel@HansenPartnership.com> Subject: Re: [tpmdd-devel] [RFC] tpm2-space: add handling for global session exhaustion From: James Bottomley To: greg@enjellic.com, Jarkko Sakkinen Cc: Ken Goldman , tpmdd-devel@lists.sourceforge.net, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org Date: Thu, 09 Feb 2017 12:05:50 -0800 In-Reply-To: <201702090906.v1996c6a015552@wind.enjellic.com> References: <201702090906.v1996c6a015552@wind.enjellic.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.16.5 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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