From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756162AbdADM6f (ORCPT ); Wed, 4 Jan 2017 07:58:35 -0500 Received: from mga04.intel.com ([192.55.52.120]:35797 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751667AbdADM6P (ORCPT ); Wed, 4 Jan 2017 07:58:15 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,459,1477983600"; d="scan'208";a="1079081210" Date: Wed, 4 Jan 2017 14:58:10 +0200 From: Jarkko Sakkinen To: Jason Gunthorpe Cc: James Bottomley , linux-security-module@vger.kernel.org, tpmdd-devel@lists.sourceforge.net, open list Subject: Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager Message-ID: <20170104125810.3qkkfe72cnb76ige@intel.com> References: <20170102132213.22880-1-jarkko.sakkinen@linux.intel.com> <1483374980.2458.13.camel@HansenPartnership.com> <20170102193320.trawto65nkjccbao@intel.com> <1483393248.2458.32.camel@HansenPartnership.com> <1483421218.19261.4.camel@linux.vnet.ibm.com> <20170103215445.GD29656@obsidianresearch.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170103215445.GD29656@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 Tue, Jan 03, 2017 at 02:54:45PM -0700, Jason Gunthorpe wrote: > On Mon, Jan 02, 2017 at 09:26:58PM -0800, James Bottomley wrote: > > > OK, so I put a patch together that does this (see below). It all works > > nicely (with a udev script that sets the resource manager device to > > 0666): > > > > jejb@jarvis:~> ls -l /dev/tpm* > > crw------- 1 root root 10, 224 Jan 2 20:54 /dev/tpm0 > > crw-rw-rw- 1 root root 246, 65536 Jan 2 20:54 /dev/tpm0rm > > > > I've modified the tss to connect to /dev/tpm0rm by default and it all > > seems to work. > > > > The patch applies on top of your tabrm branch, by the way. > > If we are making a new /dev/ node we should think more carefully about > the design. > > - Do we need a cdev node for every chip? What about just '/dev/tpm' and > we encode the chip number in the message. Since the exclusive > locking is gone this is very doable. What about backwards compatiblity? Or would this be just for /dev/tpms? We can consider this. > - Should we get rid of the read/write protocol and use ioctl instead? > As I understand it ioctl is more usable with seccomp and related > schemes? I could see passing a TPM FD into a sandbox and wanting the > sandbox only able to do do decrypt/encrypt operations, for instance. Are you suggesting that command/response transaction would be handled by ioctl instead of read/write pair. Would make sense looking at how read/write is managed now (it is more or less of a hack because it actually is a transction). > - Something to identify tpm chips and help match key data with the > proper chip. Hey, here's what I propose. I take some of the ideas (not all there have been so many) and bake a v2 of the RFC. Lets see where we are at then. I won't add any reviewed/tested-by's before we are in the same line with "big ideas" nor do I create a non-RFC patch set. > Jason /Jarkko From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jarkko Sakkinen Subject: Re: [PATCH RFC 0/4] RFC: in-kernel resource manager Date: Wed, 4 Jan 2017 14:58:10 +0200 Message-ID: <20170104125810.3qkkfe72cnb76ige@intel.com> References: <20170102132213.22880-1-jarkko.sakkinen@linux.intel.com> <1483374980.2458.13.camel@HansenPartnership.com> <20170102193320.trawto65nkjccbao@intel.com> <1483393248.2458.32.camel@HansenPartnership.com> <1483421218.19261.4.camel@linux.vnet.ibm.com> <20170103215445.GD29656@obsidianresearch.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20170103215445.GD29656-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tpmdd-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Jason Gunthorpe Cc: linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, James Bottomley , open list List-Id: tpmdd-devel@lists.sourceforge.net On Tue, Jan 03, 2017 at 02:54:45PM -0700, Jason Gunthorpe wrote: > On Mon, Jan 02, 2017 at 09:26:58PM -0800, James Bottomley wrote: > > > OK, so I put a patch together that does this (see below). It all works > > nicely (with a udev script that sets the resource manager device to > > 0666): > > > > jejb@jarvis:~> ls -l /dev/tpm* > > crw------- 1 root root 10, 224 Jan 2 20:54 /dev/tpm0 > > crw-rw-rw- 1 root root 246, 65536 Jan 2 20:54 /dev/tpm0rm > > > > I've modified the tss to connect to /dev/tpm0rm by default and it all > > seems to work. > > > > The patch applies on top of your tabrm branch, by the way. > > If we are making a new /dev/ node we should think more carefully about > the design. > > - Do we need a cdev node for every chip? What about just '/dev/tpm' and > we encode the chip number in the message. Since the exclusive > locking is gone this is very doable. What about backwards compatiblity? Or would this be just for /dev/tpms? We can consider this. > - Should we get rid of the read/write protocol and use ioctl instead? > As I understand it ioctl is more usable with seccomp and related > schemes? I could see passing a TPM FD into a sandbox and wanting the > sandbox only able to do do decrypt/encrypt operations, for instance. Are you suggesting that command/response transaction would be handled by ioctl instead of read/write pair. Would make sense looking at how read/write is managed now (it is more or less of a hack because it actually is a transction). > - Something to identify tpm chips and help match key data with the > proper chip. Hey, here's what I propose. I take some of the ideas (not all there have been so many) and bake a v2 of the RFC. Lets see where we are at then. I won't add any reviewed/tested-by's before we are in the same line with "big ideas" nor do I create a non-RFC patch set. > Jason /Jarkko ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot