From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755397AbcGTVNq (ORCPT ); Wed, 20 Jul 2016 17:13:46 -0400 Received: from quartz.orcorp.ca ([184.70.90.242]:52110 "EHLO quartz.orcorp.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754258AbcGTVNo (ORCPT ); Wed, 20 Jul 2016 17:13:44 -0400 Date: Wed, 20 Jul 2016 15:13:32 -0600 From: Jason Gunthorpe To: Jarkko Sakkinen Cc: Peter Huewe , linux-security-module@vger.kernel.org, Marcel Selhorst , "moderated list:TPM DEVICE DRIVER" , open list Subject: Re: [PATCH] tpm: fix a race condition tpm2_unseal_trusted() Message-ID: <20160720211332.GA32417@obsidianresearch.com> References: <1468973792-17598-1-git-send-email-jarkko.sakkinen@linux.intel.com> <20160720164818.GA21460@obsidianresearch.com> <20160720205314.GA6525@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160720205314.GA6525@intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Broken-Reverse-DNS: no host name found for IP address 10.0.0.151 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 20, 2016 at 11:53:14PM +0300, Jarkko Sakkinen wrote: > The only use cases I see at the moment for it work this way: > > 1. Call tpm_try_get_ops. > 2. Send a TPM command. > 3. Call tpm_put_ops. Right, but that is just a reflection of what the in kernel users are doing today, not necessarily what they should be doing. We should not break the put/get semantics.. > I did not find any other form of use. The only use is to make sure that > there are no transactions running before the ops are cleared. Or did I > overlook something perhaps? The put/get is intended to allow a kapi user to hold a ref to tpm without it geting destroyed. It is not intended to be an exclusive lock. > Trusted key unseal operation with TPM2 is broken into two operations: > > 1. Load the given key blob. > 2. Unseal the data. > > Without locking and unlocking mutex only once there is a race condition. Well, the race condition is fundamentally because we don't have key virtualization in the kernel :| Those sorts of compound ops should hold the tpm_mutex manually, not through the get_ops scheme. Jason