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] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 8 Feb 2019 15:17:54 +0200
From:   Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
To:     Stefan Berger <stefanb@...ux.ibm.com>
Cc:     Alexander Steffen <Alexander.Steffen@...ineon.com>,
        linux-integrity@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-security-module@...r.kernel.org,
        Peter Huewe <PeterHuewe@....de>,
        Jason Gunthorpe <jgg@...pe.ca>,
        Tomas Winkler <tomas.winkler@...el.com>,
        Tadeusz Struk <tadeusz.struk@...el.com>,
        Stefan Berger <stefanb@...ux.vnet.ibm.com>,
        Nayna Jain <nayna@...ux.ibm.com>
Subject: Re: [PATCH v11 00/16] Remove nested TPM operations

On Fri, Feb 08, 2019 at 08:10:32AM -0500, Stefan Berger wrote:
> On 2/8/19 8:02 AM, Jarkko Sakkinen wrote:
> > On Fri, Feb 08, 2019 at 07:05:26AM -0500, Stefan Berger wrote:
> > > See my comment on [PATCH v11 08/16]. It needs to be added in that patch
> > > since otherwise rc holds a non-zero value on function exit, which is wrong
> > > at that point.
> > The snippet in question:
> > 
> > rc = chip->ops->send(chip, buf, count);
> > if (rc < 0) {
> > 	if (rc != -EPIPE)
> > 		dev_err(&chip->dev,
> > 			"%s: tpm_send: error %d\n", __func__, rc);
> > 	return rc;
> > }
> > 
> > if (chip->flags & TPM_CHIP_FLAG_IRQ)
> > 	goto out_recv;
> > 
> > 'send()' ought to return zero on success case.
> > 
> > This is how the snippet was before applying any patches scheduled for
> > v5.1:
> > 
> > rc = chip->ops->send(chip, buf, count);
> > if (rc < 0) {
> > 	if (rc != -EPIPE)
> > 		dev_err(&chip->dev,
> > 			"%s: tpm_send: error %d\n", __func__, rc);
> > 	return rc;
> > }
> > 
> > if (chip->flags & TPM_CHIP_FLAG_IRQ)
> > 	goto out_recv;
> > 
> > Does not compute.
> 
> tpm_tis_send_main returns 'len' and that's what we have here.

Before doing any kind of code change, we should at least know what
has caused this that it has worked before.

And also which commit caused the regression to happen, because it
looks like a bug in tpm_tis_core, not in the main TPM driver. It
would need the fixes tag and cc to stable.

/Jarkko

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ