lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Wed, 22 Oct 2014 16:00:58 +0300
From:	Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
To:	Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
	peter.huewe@....de
Cc:	tpmdd-devel@...ts.sourceforge.net,
	Ashley Lai <ashley@...leylai.com>, linux-kernel@...r.kernel.org
Subject: Re: [tpmdd-devel] [PATCH] tpm: fix multiple race conditions in
 tpm_ppi.c

On Wed, Oct 22, 2014 at 01:05:33PM +0300, Jarkko Sakkinen wrote:
> On Tue, Oct 21, 2014 at 03:02:15PM -0600, Jason Gunthorpe wrote:
> > On Tue, Oct 21, 2014 at 11:42:51PM +0300, Jarkko Sakkinen wrote:
> > 
> > > > Personally, I'd sequence this commit right after your 'tpm: two-phase
> > > > chip management functions' commit because it makes it much saner (no
> > > > half step toward the new functions). I assume this is a theoretical
> > > > problem? Or do you have a two TPM system?
> > > 
> > > This has realized in Intel NUCs where there is PTT and dTPM module. Even
> > > when PTT is selected there is still ACPI device for dTPM so three is a
> > > race condition and PPI is unusable. I think that it's not good that code is
> > > not robust enough to deal with this.
> > 
> > Oh OK, you should probably explain in the commit log that this is a
> > bug fix that impacts real hardware, that qualifies it for the -stable
> > tree.
> > 
> > Assuming two-phase commit is nearly ready to go, I'd still sequence
> > this fix after two-phase for mainline and then use this patch as-is
> > for the 3.17 -stable backport of the mainline commit.
> 
> OK, makes sense. I'll try to get this done tonight.

I propose that the current fix would be actually taken into 3.18 as it
is and bigger changes would be introduced for 3.19 as the merge window
is closed. I do not think it would be wise at this point to make larger
structural changes.

I could however update the commit message and copyright platter
(should have 2012-2014, not just 2014). What do you think? Peter?

/Jarkko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ