From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757855AbcH2PZ3 (ORCPT ); Mon, 29 Aug 2016 11:25:29 -0400 Received: from mga14.intel.com ([192.55.52.115]:8685 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757556AbcH2PZ2 (ORCPT ); Mon, 29 Aug 2016 11:25:28 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,597,1464678000"; d="scan'208";a="2316755" Date: Mon, 29 Aug 2016 18:25:21 +0300 From: Jarkko Sakkinen To: Jason Gunthorpe Cc: Peter Huewe , linux-security-module@vger.kernel.org, stable@vger.kernel.org, Marcel Selhorst , "moderated list:TPM DEVICE DRIVER" , open list Subject: Re: [PATCH] tpm: fix a race condition in tpm2_unseal_trusted() Message-ID: <20160829152520.GA9063@intel.com> References: <1472366212-8571-1-git-send-email-jarkko.sakkinen@linux.intel.com> <20160828185149.GF12783@obsidianresearch.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160828185149.GF12783@obsidianresearch.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Aug 28, 2016 at 12:51:49PM -0600, Jason Gunthorpe wrote: > On Sun, Aug 28, 2016 at 08:36:52AM +0200, Jarkko Sakkinen wrote: > > > > @@ -576,7 +576,8 @@ static int tpm2_load(struct tpm_chip *chip, > > goto out; > > } > > > > - rc = tpm_transmit_cmd(chip, buf.data, PAGE_SIZE, "loading blob"); > > + rc = tpm_transmit_cmd(chip, buf.data, PAGE_SIZE, TPM_TRANSMIT_UNLOCKED, > > + "loading blob"); > > I still don't like this, required mutex's should not be split outside the > function that needs them without more a more obvious indication: > > > + mutex_lock(&chip->tpm_mutex); > > rc = tpm2_load(chip, payload, options, &blob_handle); > > if (rc) > > - return rc; > > I recommend you stick with the idiom and do this: > > mutex_lock(&chip->tpm_mutex); > rc = tpm2_load(chip, payload, options, &blob_handle, TPM_TRANSMIT_UNLOCKED); > > Which makes it easy to see we are doing it right everywhere. Why consume stack for unnecessary stuff? This is a static function. For me this sounds like cutting hairs really. One thing that would improve readability would be to rename internal functions tpm2_load and tpm2_unseal to tpm2_load_cmd and tpm2_unseal_cmd in order to underline that they are command wrappers and not to mix with tpm2_unseal_trusted(). I've been thinking to move that kind of convetion at least with TPM2 specific stuff when a function is clearly a wrapper. It kind of documents the call path. I.e. if function satifies a constraint that it prepares a command blob, calls tpm_transmit_cmd once and then returns results to the caller this would be the naming convention. > Jason /Jarkko From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com ([192.55.52.115]:8685 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757556AbcH2PZ2 (ORCPT ); Mon, 29 Aug 2016 11:25:28 -0400 Date: Mon, 29 Aug 2016 18:25:21 +0300 From: Jarkko Sakkinen To: Jason Gunthorpe Cc: Peter Huewe , linux-security-module@vger.kernel.org, stable@vger.kernel.org, Marcel Selhorst , "moderated list:TPM DEVICE DRIVER" , open list Subject: Re: [PATCH] tpm: fix a race condition in tpm2_unseal_trusted() Message-ID: <20160829152520.GA9063@intel.com> References: <1472366212-8571-1-git-send-email-jarkko.sakkinen@linux.intel.com> <20160828185149.GF12783@obsidianresearch.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160828185149.GF12783@obsidianresearch.com> Sender: stable-owner@vger.kernel.org List-ID: On Sun, Aug 28, 2016 at 12:51:49PM -0600, Jason Gunthorpe wrote: > On Sun, Aug 28, 2016 at 08:36:52AM +0200, Jarkko Sakkinen wrote: > > > > @@ -576,7 +576,8 @@ static int tpm2_load(struct tpm_chip *chip, > > goto out; > > } > > > > - rc = tpm_transmit_cmd(chip, buf.data, PAGE_SIZE, "loading blob"); > > + rc = tpm_transmit_cmd(chip, buf.data, PAGE_SIZE, TPM_TRANSMIT_UNLOCKED, > > + "loading blob"); > > I still don't like this, required mutex's should not be split outside the > function that needs them without more a more obvious indication: > > > + mutex_lock(&chip->tpm_mutex); > > rc = tpm2_load(chip, payload, options, &blob_handle); > > if (rc) > > - return rc; > > I recommend you stick with the idiom and do this: > > mutex_lock(&chip->tpm_mutex); > rc = tpm2_load(chip, payload, options, &blob_handle, TPM_TRANSMIT_UNLOCKED); > > Which makes it easy to see we are doing it right everywhere. Why consume stack for unnecessary stuff? This is a static function. For me this sounds like cutting hairs really. One thing that would improve readability would be to rename internal functions tpm2_load and tpm2_unseal to tpm2_load_cmd and tpm2_unseal_cmd in order to underline that they are command wrappers and not to mix with tpm2_unseal_trusted(). I've been thinking to move that kind of convetion at least with TPM2 specific stuff when a function is clearly a wrapper. It kind of documents the call path. I.e. if function satifies a constraint that it prepares a command blob, calls tpm_transmit_cmd once and then returns results to the caller this would be the naming convention. > Jason /Jarkko