From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1162327AbdAJUGR (ORCPT ); Tue, 10 Jan 2017 15:06:17 -0500 Received: from quartz.orcorp.ca ([184.70.90.242]:37028 "EHLO quartz.orcorp.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965503AbdAJUGQ (ORCPT ); Tue, 10 Jan 2017 15:06:16 -0500 Date: Tue, 10 Jan 2017 13:05:58 -0700 From: Jason Gunthorpe To: Jarkko Sakkinen Cc: greg@enjellic.com, tpmdd-devel@lists.sourceforge.net, linux-security-module@vger.kernel.org, Ken Goldman , linux-kernel@vger.kernel.org Subject: Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager Message-ID: <20170110200558.GA5102@obsidianresearch.com> References: <201701041612.v04GCfPK031525@wind.enjellic.com> <20170109231635.6wh25qoy7svcnys6@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170109231635.6wh25qoy7svcnys6@intel.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 Tue, Jan 10, 2017 at 01:16:35AM +0200, Jarkko Sakkinen wrote: > On Wed, Jan 04, 2017 at 10:12:41AM -0600, Dr. Greg Wettstein wrote: > > The kernel needs a resource manager. Everyone needs to think VERY > > hard and VERY, VERY carefully about what gets put into the kernel. In > > making a decision, put the ABSOLUTE smallest amount of code into the > > kernel which allows various 'TPM2 personalities' to be implemented in > > userspace and functionally verified and protected by the physical > > instance. The emergence of commodity TEE's (SGX, et.al) should be in > > the back of everyone's mind as a factor in the roadmap. > > Here's my cuts for the kernel: > > - Kernel virtualizes handle areas. It's mechanical. > - Kernel does not virtualize bodies. It's not mechanical. > - At least the first version of the RM will not do other than session > isolation for sessions. > > This keeps the core for RM inside the kernel small and tight. I think this makes sense. In addition the kernel should only permit RM operations that are known to be 100% correct with the RM. I think you should stick with your original design basic design, except instead of using an ioctl to switch modes, use an ioctl to execute the operation: struct tpm_ioctl_operation { u16 mode; // == TPM1_RAW,TPM2_RAW,TPM1_RM,TPM2_RM u16 locality; u32 txlen; u32 rxlen; const void *txbuf; void *rxbuf; }; The userspace broker would be expected to use a mixture of RM and RAW operations. Let's deal with the idea of another cdev some other day when someone can figure out a comprehensive way to do that securely for unpriv.. Jason