From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754974AbdAKTEg (ORCPT ); Wed, 11 Jan 2017 14:04:36 -0500 Received: from quartz.orcorp.ca ([184.70.90.242]:47869 "EHLO quartz.orcorp.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750807AbdAKTEe (ORCPT ); Wed, 11 Jan 2017 14:04:34 -0500 Date: Wed, 11 Jan 2017 12:04:28 -0700 From: Jason Gunthorpe To: James Bottomley Cc: Ken Goldman , greg@enjellic.com, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, tpmdd-devel@lists.sourceforge.net Subject: Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager Message-ID: <20170111190428.GA17873@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> <20170111175657.GA22783@obsidianresearch.com> <1484159157.2509.23.camel@HansenPartnership.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1484159157.2509.23.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 10:25:57AM -0800, James Bottomley wrote: > Right, but we're going around in circles. I'm currently researching > what it would take to be daemonless, so an ioctl which requires an > access broker daemon would obviously be something I'd object to. Well, when we figure out a security model that works for that and can be implemented in the kernel then lets add the new cdev. But that is *explicitly* not what Jarkko is doing, no reason to jump the gun. > Basically, though, I think you can do both: we can add an ioctl and the > differing device hooks. I just think for that case RAW vs RM would be > redundant. Right, some future new cdev would only support ioctl and only the RM path, but for priv use having both concurrently available makes sense as a userspace broker producing a full RM will need to using both paths. Jason