From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936189AbdACVzJ (ORCPT ); Tue, 3 Jan 2017 16:55:09 -0500 Received: from quartz.orcorp.ca ([184.70.90.242]:38556 "EHLO quartz.orcorp.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964958AbdACVy4 (ORCPT ); Tue, 3 Jan 2017 16:54:56 -0500 Date: Tue, 3 Jan 2017 14:54:45 -0700 From: Jason Gunthorpe To: James Bottomley Cc: Jarkko Sakkinen , 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: <20170103215445.GD29656@obsidianresearch.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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1483421218.19261.4.camel@linux.vnet.ibm.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Broken-Reverse-DNS: no host name found for IP address 10.0.0.156 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. - 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. - Something to identify tpm chips and help match key data with the proper chip. Jason