From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752743AbdBJIsn (ORCPT ); Fri, 10 Feb 2017 03:48:43 -0500 Received: from mga11.intel.com ([192.55.52.93]:55747 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752607AbdBJIsl (ORCPT ); Fri, 10 Feb 2017 03:48:41 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.35,140,1484035200"; d="scan'208";a="64110520" Date: Fri, 10 Feb 2017 10:48:37 +0200 From: Jarkko Sakkinen To: Jason Gunthorpe Cc: greg@enjellic.com, James Bottomley , tpmdd-devel@lists.sourceforge.net, linux-security-module@vger.kernel.org, Ken Goldman , linux-kernel@vger.kernel.org Subject: Re: [tpmdd-devel] [RFC] tpm2-space: add handling for global session exhaustion Message-ID: <20170210084837.lq3mofgfwvjx623m@intel.com> References: <201702090906.v1996c6a015552@wind.enjellic.com> <20170209151922.cqo32h4io5dqyvvw@intel.com> <20170209190426.GA1104@obsidianresearch.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170209190426.GA1104@obsidianresearch.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo User-Agent: Mutt/1.6.2-neo (2016-08-21) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 09, 2017 at 12:04:26PM -0700, Jason Gunthorpe wrote: > On Thu, Feb 09, 2017 at 05:19:22PM +0200, Jarkko Sakkinen wrote: > > > userspace instance with subsequent relinquishment of privilege. At > > > that point one has the freedom to implement all sorts of policy. > > > > If you look at the patch set that I sent yesterday it exactly has a > > feature that makes it more lean for a privileged process to implement > > a resource manager. > > I continue to think, based on comments like this, that you should not > implement tmps0 in the first revision either. That is also something > we have to live with forever, and it can never become the 'policy > limited' or 'unpriv safe' access point to the kernel. ie go back to > something based on tmp0 with ioctl. With /dev/tpms0 I'm fairly certain that it is right way to go as it does make sense to have it as close as being drop in replacement for /dev/tpm0 as possible. There's factors more certainty that the API is something that most people will like to have. > This series should focus on allowing a user space RM to co-exist with > the in-kernel services - lets try and tackle the idea of a > policy-restricted or unpriv-safe cdev when someone comes up with a > comprehensive proposal.. Sure. I do agree with this. > > The current patch set does not define policy. The simple policy > > addition that could be added soon is the limit of connections > > because it is easy to implement in non-intrusive way. > > It is also trivial for a userspace RM to limit the number of sessions > or connections or otherwise to manage this limitation. It is hard to > see why we'd need kernel support for this. > > The main issue from the kernel perspecitive is how to allow sessions > to be used in-kernel and continue to make progress when they start to > run out. > > Jason This is an issue but in the current patch set there's nothing that would make it harder to sort out. /Jarkko