From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751386AbdCVUK3 (ORCPT ); Wed, 22 Mar 2017 16:10:29 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:56377 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750903AbdCVUKX (ORCPT ); Wed, 22 Mar 2017 16:10:23 -0400 Subject: Re: [tpmdd-devel] [PATCH v2 4/7] tpm: infrastructure for TPM spaces To: tpmdd-devel@lists.sourceforge.net References: <20170216192529.25467-1-jarkko.sakkinen@linux.intel.com> <20170216192529.25467-5-jarkko.sakkinen@linux.intel.com> <58AC85F2.5000406@linux.vnet.ibm.com> <1487785159.2376.27.camel@HansenPartnership.com> Cc: linux-security-module@vger.kernel.org, open list Newsgroups: gmane.linux.kernel.lsm,gmane.comp.encryption.tpmdd.devel,gmane.linux.kernel From: Ken Goldman Date: Wed, 22 Mar 2017 16:09:21 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1487785159.2376.27.camel@HansenPartnership.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 17032220-0016-0000-0000-0000066C4CF3 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00006830; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000206; SDB=6.00837451; UDB=6.00411702; IPR=6.00615217; BA=6.00005232; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00014762; XFM=3.00000013; UTC=2017-03-22 20:09:19 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17032220-0017-0000-0000-00003860EC2C Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-03-22_17:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=1 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703220173 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2/22/2017 12:39 PM, James Bottomley wrote: > > Right at the moment the kernel use of tpm2 looks like > > acquire chip->tpm_mutex > load key > process key > unload key > release chip->tpm_mutex > > While it does this, there's no need for it to have a RM interface > because what it does between the acquisition and drop of the mutex > can't be seen by or have any effect on userspace (whether it uses the > RM or not). So currently, the question doesn't arise, which is the > situation you see. 1 - This appears to depend on the RM not releasing the mutex until all objects are swapped out. Correct? Same for sessions? 2 - A startauthsession can cause a regap error. Does the above depend on the RM doing early regapping so the RM won't see that error? 3 - There's also the problem where the TPM saved session slots (typically 64) are full. My intuition is that the best solution is for the RM to reserve 3 slots for the kernel.