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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason Gunthorpe Subject: Re: [PATCH] tpm: fix a race condition tpm2_unseal_trusted() Date: Wed, 20 Jul 2016 15:13:32 -0600 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-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20160720205314.GA6525-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tpmdd-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Jarkko Sakkinen Cc: "moderated list:TPM DEVICE DRIVER" , linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, open list List-Id: tpmdd-devel@lists.sourceforge.net 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 ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports.http://sdm.link/zohodev2dev