From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S967276AbdADB1e (ORCPT ); Tue, 3 Jan 2017 20:27:34 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:55213 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965614AbdADB1W (ORCPT ); Tue, 3 Jan 2017 20:27:22 -0500 Subject: Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager From: James Bottomley To: Jarkko Sakkinen Cc: linux-security-module@vger.kernel.org, tpmdd-devel@lists.sourceforge.net, open list Date: Tue, 03 Jan 2017 11:34:29 -0800 In-Reply-To: <20170103191456.vpl6ny7rbgu3yigx@intel.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> <20170103134100.stgxkmzbckon4jfb@intel.com> <1483460095.2464.6.camel@linux.vnet.ibm.com> <20170103183602.ar5typcvy2rx7cjs@intel.com> <20170103191456.vpl6ny7rbgu3yigx@intel.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.16.5 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 17010319-0040-0000-0000-00000243E27A X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00006367; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000199; SDB=6.00803051; UDB=6.00390630; IPR=6.00580902; BA=6.00005028; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00013812; XFM=3.00000011; UTC=2017-01-03 19:34:34 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17010319-0041-0000-0000-00000636E4A7 Message-Id: <1483472069.2464.24.camel@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-01-03_17:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1701030299 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2017-01-03 at 21:14 +0200, Jarkko Sakkinen wrote: > On Tue, Jan 03, 2017 at 08:36:02PM +0200, Jarkko Sakkinen wrote: > > On Tue, Jan 03, 2017 at 08:14:55AM -0800, James Bottomley wrote: > > > On Tue, 2017-01-03 at 15:41 +0200, Jarkko Sakkinen wrote: [...] > > > > Just thinking how to split up the non-RFC patch set. This was > > > > also what Jason suggested if I understood his remark correctly. > > > > > > SUre ... let's get agreement on how we move forward first. How > > > the patch is activated by the user has to be sorted out as well > > > before it can go in, but it doesn't have to be the first thing we > > > do. I'm happy to continue playing with the interfaces to see > > > what works and what doesn't. My main current feedback is that I > > > think separate devices works way better than an ioctl becuase the > > > separate devices approach allows differing system policies for > > > who accesses the RM backed TPM vs who accesses the raw one. > > > > I think I see your point. I would rather name the device as tpms0 > > but otherwise I think we could do it in the way you suggest... I'm not at all wedded to the name tpm0rm, so tpms0 is fine by me. > I think one more stronger argument for tpms0 is that it keeps tpm0 > intact. Those who don't care about tpms0 don't have to worry about it > causing regressions. Also it makes it cleaner to put the whole > feature under a compilation flag, which would make to me because that > gives distributions a choice to not enable in-kernel RM when it first > hits the mainline. I wouldn't go that far: one of the evils we cause for distros is too many compile options. In this case, I can't think of a good reason to have an option to disable this now the feature is segregated on to a separate device. If we get a regression, only users of the new device will notice. If it's a compile option, this is the same if the distro enables it and if it's disabled, no user can test out the feature (and distros eventually get complaints about it not working). James