From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason Gunthorpe Subject: Re: [PATCH RFC 0/4] RFC: in-kernel resource manager Date: Wed, 11 Jan 2017 10:56:57 -0700 Message-ID: <20170111175657.GA22783@obsidianresearch.com> References: <201701041612.v04GCfPK031525@wind.enjellic.com> <20170109231635.6wh25qoy7svcnys6@intel.com> <20170110200558.GA5102@obsidianresearch.com> <20170111113416.4h6ucm5y3hjjnfhv@intel.com> <1484149193.2509.12.camel@HansenPartnership.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <1484149193.2509.12.camel-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tpmdd-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: James Bottomley Cc: Ken Goldman , greg-R92VP3DqSWVWk0Htik3J/w@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: tpmdd-devel@lists.sourceforge.net On Wed, Jan 11, 2017 at 07:39:53AM -0800, James Bottomley wrote: > RAW access means the ability to DoS the TPM simply by exhausting > handles. Therefore, I think most applications only get RM access. Re-read what Jarkko is proposing. He is not making a complete safe & secure RM in the kernel. He is making a tool to allow userspace and the kernel to share the TPM sanely. It is not an access control tool, it is not a security tool, it is not intended to support safe unpriv userspace access. So there is no reason to have a different access control model in userspace, it is not a fundamentally different security environment from the existing raw device. A future project to provide an unpriv safe cdev from the kernel is something different. Jason ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S939099AbdAKR5O (ORCPT ); Wed, 11 Jan 2017 12:57:14 -0500 Received: from quartz.orcorp.ca ([184.70.90.242]:57639 "EHLO quartz.orcorp.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S938930AbdAKR5K (ORCPT ); Wed, 11 Jan 2017 12:57:10 -0500 Date: Wed, 11 Jan 2017 10:56:57 -0700 From: Jason Gunthorpe To: James Bottomley Cc: Jarkko Sakkinen , Ken Goldman , tpmdd-devel@lists.sourceforge.net, linux-security-module@vger.kernel.org, greg@enjellic.com, linux-kernel@vger.kernel.org Subject: Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager Message-ID: <20170111175657.GA22783@obsidianresearch.com> References: <201701041612.v04GCfPK031525@wind.enjellic.com> <20170109231635.6wh25qoy7svcnys6@intel.com> <20170110200558.GA5102@obsidianresearch.com> <20170111113416.4h6ucm5y3hjjnfhv@intel.com> <1484149193.2509.12.camel@HansenPartnership.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1484149193.2509.12.camel@HansenPartnership.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 Wed, Jan 11, 2017 at 07:39:53AM -0800, James Bottomley wrote: > RAW access means the ability to DoS the TPM simply by exhausting > handles. Therefore, I think most applications only get RM access. Re-read what Jarkko is proposing. He is not making a complete safe & secure RM in the kernel. He is making a tool to allow userspace and the kernel to share the TPM sanely. It is not an access control tool, it is not a security tool, it is not intended to support safe unpriv userspace access. So there is no reason to have a different access control model in userspace, it is not a fundamentally different security environment from the existing raw device. A future project to provide an unpriv safe cdev from the kernel is something different. Jason