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