From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1763331AbdAESeK (ORCPT ); Thu, 5 Jan 2017 13:34:10 -0500 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:36451 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751357AbdAESeH (ORCPT ); Thu, 5 Jan 2017 13:34:07 -0500 Subject: Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager From: James Bottomley To: Jason Gunthorpe , "Fuchs, Andreas" Cc: "linux-security-module@vger.kernel.org" , "tpmdd-devel@lists.sourceforge.net" , open list Date: Thu, 05 Jan 2017 10:33:43 -0800 In-Reply-To: <20170105172726.GA11680@obsidianresearch.com> References: <20170102132213.22880-1-jarkko.sakkinen@linux.intel.com> <9F48E1A823B03B4790B7E6E69430724DC7C149F6@exch2010c.sit.fraunhofer.de> <20170105172726.GA11680@obsidianresearch.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: 17010518-0020-0000-0000-00000AA9385E X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00006379; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000199; SDB=6.00803990; UDB=6.00391194; IPR=6.00581838; BA=6.00005031; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00013834; XFM=3.00000011; UTC=2017-01-05 18:33:49 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17010518-0021-0000-0000-000058A051A7 Message-Id: <1483641223.2515.62.camel@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-01-05_13:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=2 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1701050277 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2017-01-05 at 10:27 -0700, Jason Gunthorpe wrote: > On Thu, Jan 05, 2017 at 03:52:02PM +0000, Fuchs, Andreas wrote: [...] > > - Session Limits (here it gets ugly): > > > Even thought the TPM supports the same swapping-scheme for sessions > > as it does for transient objects, it only allows for a limited > > number of session to be opened (64 in case of PC-Client), called > > active sessions. This means that a single process can still DoS > > the TPM if it allocates 64 sessions, or 64 processes can DoS the > > TPM if > > Well, if we have an unpriv fd then it should not be able to DOS the > system - that would suggest either that FD cannot use sessions or we > need some kernel solution to guarentee the DOS is not possible. The sessions issue is a bit of a monster nightmare. The basic problem is this issue that they're not fully virtualizable: the TPM retains knowledge that a session existed on this handle even if the session context is offloaded. It's this space for "session exists" that the TPM has a limited space for. > A combo ioctl that could setup the session, issue an operation in it > and then delete the session, for instance. This would work for encryption or HMAC sessions, but probably not for policy sessions, because they can have an arbitrarily large command sequence to construct them. The other issue we're likely to run into if we do it this way is delayed error reporting. How about a more traditional approach which would be leasing (basically what we use for NFS). Any application opening a session would have a certain time (probably in ms) to complete it or we'd close the handle and flush it. We'd store the jiffies time the session was first requested and loop over all the extent sessions to find ones which get too old. We know there can only be TPM_PT_ACTIVE_SESSIONS_MAX of these, so it's a cheap operation. It's only a small extra bit of logic to take care of the GAP problem as well, I think. If we're full when you try and start a session, we block you until a handle becomes free and the max lease time guarantees when this is. James From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Bottomley Subject: Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager Date: Thu, 05 Jan 2017 10:33:43 -0800 Message-ID: <1483641223.2515.62.camel@linux.vnet.ibm.com> References: <20170102132213.22880-1-jarkko.sakkinen@linux.intel.com> <9F48E1A823B03B4790B7E6E69430724DC7C149F6@exch2010c.sit.fraunhofer.de> <20170105172726.GA11680@obsidianresearch.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20170105172726.GA11680@obsidianresearch.com> Sender: owner-linux-security-module@vger.kernel.org To: Jason Gunthorpe , "Fuchs, Andreas" Cc: "linux-security-module@vger.kernel.org" , "tpmdd-devel@lists.sourceforge.net" , open list List-Id: tpmdd-devel@lists.sourceforge.net On Thu, 2017-01-05 at 10:27 -0700, Jason Gunthorpe wrote: > On Thu, Jan 05, 2017 at 03:52:02PM +0000, Fuchs, Andreas wrote: [...] > > - Session Limits (here it gets ugly): > > > Even thought the TPM supports the same swapping-scheme for sessions > > as it does for transient objects, it only allows for a limited > > number of session to be opened (64 in case of PC-Client), called > > active sessions. This means that a single process can still DoS > > the TPM if it allocates 64 sessions, or 64 processes can DoS the > > TPM if > > Well, if we have an unpriv fd then it should not be able to DOS the > system - that would suggest either that FD cannot use sessions or we > need some kernel solution to guarentee the DOS is not possible. The sessions issue is a bit of a monster nightmare. The basic problem is this issue that they're not fully virtualizable: the TPM retains knowledge that a session existed on this handle even if the session context is offloaded. It's this space for "session exists" that the TPM has a limited space for. > A combo ioctl that could setup the session, issue an operation in it > and then delete the session, for instance. This would work for encryption or HMAC sessions, but probably not for policy sessions, because they can have an arbitrarily large command sequence to construct them. The other issue we're likely to run into if we do it this way is delayed error reporting. How about a more traditional approach which would be leasing (basically what we use for NFS). Any application opening a session would have a certain time (probably in ms) to complete it or we'd close the handle and flush it. We'd store the jiffies time the session was first requested and loop over all the extent sessions to find ones which get too old. We know there can only be TPM_PT_ACTIVE_SESSIONS_MAX of these, so it's a cheap operation. It's only a small extra bit of logic to take care of the GAP problem as well, I think. If we're full when you try and start a session, we block you until a handle becomes free and the max lease time guarantees when this is. James