From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1032903AbdAFTLH (ORCPT ); Fri, 6 Jan 2017 14:11:07 -0500 Received: from quartz.orcorp.ca ([184.70.90.242]:39514 "EHLO quartz.orcorp.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1032828AbdAFTK6 (ORCPT ); Fri, 6 Jan 2017 14:10:58 -0500 Date: Fri, 6 Jan 2017 12:10:49 -0700 From: Jason Gunthorpe To: Andreas Fuchs Cc: James Bottomley , "linux-security-module@vger.kernel.org" , "tpmdd-devel@lists.sourceforge.net" , open list Subject: Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager Message-ID: <20170106191049.GA19576@obsidianresearch.com> References: <9F48E1A823B03B4790B7E6E69430724DC7C149F6@exch2010c.sit.fraunhofer.de> <20170105172726.GA11680@obsidianresearch.com> <1483641223.2515.62.camel@linux.vnet.ibm.com> <20170105192025.GB12587@obsidianresearch.com> <1483646149.2515.83.camel@linux.vnet.ibm.com> <20170105222118.GC31047@obsidianresearch.com> <1483657126.2515.107.camel@linux.vnet.ibm.com> <20170105235046.GA4670@obsidianresearch.com> <1483663002.2515.134.camel@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Fri, Jan 06, 2017 at 09:59:57AM +0100, Andreas Fuchs wrote: > 1. PolicyPCR is an essential feature of TPM used all over the place, > so we need support for policy sessions. > 2. PolicySigned allows authentication of the user via SmartCard. Are smart cards 0666 in linux? > The all-defeating reason for having in-kernel-RM is trusted keyrings > or IMA/EVM appraise/protect or similar. They will want to use sealing > to PCRs which in turn requires policy sessions from inside the kernel > and thus RM inside the kernel to play nicely with the TSS. Yes. I had hoped the in-kernel-RM could also provide safe 0666 access, but lets move on from that idea and focus on kernel/user TPM application co-existence... > And IMHO nobody wants the kernel security modules to call back to a > userspace RM-daemon. Yep. > If everyone agrees with this presumption the only question becomes > how to do this, such that we don't need a second RM in userspace > for the 99% of use cases. Yep. > P.S. This fact should also be given some thought when discussing the > priviledged 0600 node, i.e. /dev/tpm0 without the s in the middle. We are stuck with the non-RM interface for compat. There could be a kernel option/module option/sysctl/whatever of some kind to disable it I guess. Jason