From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754934AbcHYVSo (ORCPT ); Thu, 25 Aug 2016 17:18:44 -0400 Received: from mga06.intel.com ([134.134.136.31]:40453 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751672AbcHYVSf (ORCPT ); Thu, 25 Aug 2016 17:18:35 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,577,1464678000"; d="scan'208";a="753533141" Date: Thu, 25 Aug 2016 17:06:10 -0400 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 tpm2_unseal_trusted() Message-ID: <20160825210437.GA8658@intel.com> References: <1472000243-7088-1-git-send-email-jarkko.sakkinen@linux.intel.com> <20160825183059.GB1142@obsidianresearch.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160825183059.GB1142@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 Thu, Aug 25, 2016 at 12:30:59PM -0600, Jason Gunthorpe wrote: > On Tue, Aug 23, 2016 at 08:57:22PM -0400, Jarkko Sakkinen wrote: > > > + if (flags & TPM_TRANSMIT_LOCK) > > + mutex_lock(&chip->tpm_mutex); > > I think I would invert this. UNLOCKED is the exceptional case, so I'd > make the 0 flags lock. If we see UNLOCKED in the caller then we know > to audit for locking, 0 is much less obvious. I'm fine with either way. > > @@ -576,7 +576,7 @@ 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, "loading blob", 0); > > All these points should accept a flags too and the caller should pass > in the TPM_TRASNMIT_UNLOCKED if it needs it.. For this bug fix it makes sense to implement it the way I did because it needs to be applied to multiple releases (I think I've underlined this in my changelog). If you think this is high priority, I can make the next revision into patch set of two patches. The second patch would implement the change you suggested. /Jarkko From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga06.intel.com ([134.134.136.31]:40453 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751672AbcHYVSf (ORCPT ); Thu, 25 Aug 2016 17:18:35 -0400 Date: Thu, 25 Aug 2016 17:06:10 -0400 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 tpm2_unseal_trusted() Message-ID: <20160825210437.GA8658@intel.com> References: <1472000243-7088-1-git-send-email-jarkko.sakkinen@linux.intel.com> <20160825183059.GB1142@obsidianresearch.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160825183059.GB1142@obsidianresearch.com> Sender: stable-owner@vger.kernel.org List-ID: On Thu, Aug 25, 2016 at 12:30:59PM -0600, Jason Gunthorpe wrote: > On Tue, Aug 23, 2016 at 08:57:22PM -0400, Jarkko Sakkinen wrote: > > > + if (flags & TPM_TRANSMIT_LOCK) > > + mutex_lock(&chip->tpm_mutex); > > I think I would invert this. UNLOCKED is the exceptional case, so I'd > make the 0 flags lock. If we see UNLOCKED in the caller then we know > to audit for locking, 0 is much less obvious. I'm fine with either way. > > @@ -576,7 +576,7 @@ 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, "loading blob", 0); > > All these points should accept a flags too and the caller should pass > in the TPM_TRASNMIT_UNLOCKED if it needs it.. For this bug fix it makes sense to implement it the way I did because it needs to be applied to multiple releases (I think I've underlined this in my changelog). If you think this is high priority, I can make the next revision into patch set of two patches. The second patch would implement the change you suggested. /Jarkko From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jarkko Sakkinen Subject: Re: [PATCH] tpm: fix a race condition tpm2_unseal_trusted() Date: Thu, 25 Aug 2016 17:06:10 -0400 Message-ID: <20160825210437.GA8658@intel.com> References: <1472000243-7088-1-git-send-email-jarkko.sakkinen@linux.intel.com> <20160825183059.GB1142@obsidianresearch.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20160825183059.GB1142-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tpmdd-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Jason Gunthorpe Cc: open list , stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, "moderated list:TPM DEVICE DRIVER" List-Id: tpmdd-devel@lists.sourceforge.net On Thu, Aug 25, 2016 at 12:30:59PM -0600, Jason Gunthorpe wrote: > On Tue, Aug 23, 2016 at 08:57:22PM -0400, Jarkko Sakkinen wrote: > > > + if (flags & TPM_TRANSMIT_LOCK) > > + mutex_lock(&chip->tpm_mutex); > > I think I would invert this. UNLOCKED is the exceptional case, so I'd > make the 0 flags lock. If we see UNLOCKED in the caller then we know > to audit for locking, 0 is much less obvious. I'm fine with either way. > > @@ -576,7 +576,7 @@ 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, "loading blob", 0); > > All these points should accept a flags too and the caller should pass > in the TPM_TRASNMIT_UNLOCKED if it needs it.. For this bug fix it makes sense to implement it the way I did because it needs to be applied to multiple releases (I think I've underlined this in my changelog). If you think this is high priority, I can make the next revision into patch set of two patches. The second patch would implement the change you suggested. /Jarkko ------------------------------------------------------------------------------