From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964911AbdACQRH (ORCPT ); Tue, 3 Jan 2017 11:17:07 -0500 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:39038 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S964800AbdACQQe (ORCPT ); Tue, 3 Jan 2017 11:16:34 -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 08:14:55 -0800 In-Reply-To: <20170103134100.stgxkmzbckon4jfb@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> 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: 17010316-8235-0000-0000-00000A4ABB84 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00006366; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000199; SDB=6.00802985; UDB=6.00390591; IPR=6.00580835; 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.00013810; XFM=3.00000011; UTC=2017-01-03 16:15:00 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17010316-8236-0000-0000-0000381A7E00 Message-Id: <1483460095.2464.6.camel@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-01-03_13:,, 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-1701030254 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2017-01-03 at 15:41 +0200, Jarkko Sakkinen wrote: > On Mon, Jan 02, 2017 at 09:26:58PM -0800, James Bottomley wrote: > > On Mon, 2017-01-02 at 13:40 -0800, James Bottomley wrote: > > > On Mon, 2017-01-02 at 21:33 +0200, Jarkko Sakkinen wrote: > > > > On Mon, Jan 02, 2017 at 08:36:20AM -0800, James Bottomley > > > > wrote: > > > > > On Mon, 2017-01-02 at 15:22 +0200, Jarkko Sakkinen wrote: > > > > > > This patch set adds support for TPM spaces that provide a > > > > > > context for isolating and swapping transient objects. This > > > > > > patch set does not yet include support for isolating policy > > > > > > and HMAC sessions but it is trivial to add once the basic > > > > > > approach is settled (and that's why I created an RFC patch > > > > > > set). > > > > > > > > > > The approach looks fine to me. The only basic query I have > > > > > is about the default: shouldn't it be with resource manager > > > > > on rather than off? I can't really think of a use case that > > > > > wants the RM off (even if you're running your own, having > > > > > another doesn't hurt anything, and it's still required to > > > > > share with in-kernel uses). > > > > > > > > This is a valid question and here's a longish explanation. > > > > > > > > In TPM2_GetCapability and maybe couple of other commands you > > > > can get handles in the response body. I do not want to have > > > > special cases in the kernel for response bodies because there > > > > is no a generic way to do the substitution. What's worse, new > > > > commands in the standard future revisions could have such > > > > commands requiring special cases. In addition, vendor specific > > > > commans could have handles in the response bodies. > > > > > > OK, in general I buy this ... what you're effectively saying is > > > that we need a non-RM interface for certain management type > > > commands. > > > > > > However, let me expand a bit on why I'm fretting about the non-RM > > > use case. Right at the moment, we have a single TPM device which > > > you use for access to the kernel TPM. The current tss2 just > > > makes direct use of this, meaning it has to have 0666 > > > permissions. This means that any local user can simply DoS the > > > TPM by running us out of transient resources if they don't > > > activate the RM. If they get a connection always via the RM, > > > this isn't a worry. Perhaps the best way of fixing this is to > > > expose two separate device nodes: one raw to the TPM which we > > > could keep at 0600 and one with an always RM connection > > > which we can set to 0666. That would mean that access to the non > > > -RM connection is either root only or governed by a system set > > > ACL. > > > > OK, so I put a patch together that does this (see below). It all > > works nicely (with a udev script that sets the resource manager > > device to 0666): > > This is not yet a comment about this suggestion but I guess one thing > is clear: the stuff in tpm2-space.c and tpm-interface.c changes are > the thing that we can mostly agree on and the area of argumentation > is the user space interface to it? Agreed. As I've already said, the space and interface code is working well for me in production on my laptop. > 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. James