Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Wed, 23 Jan 2019 22:11:00 +0200
From:   Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To:     Linus Torvalds <torvalds@linux-foundation.org>,
        tomas.winkler@intel.com
Cc:     Jason Gunthorpe <jgg@ziepe.ca>,
        James Bottomley <James.Bottomley@hansenpartnership.com>,
        linux-integrity@vger.kernel.org,
        linux-security-module@vger.kernel.org,
        Linux List Kernel Mailing <linux-kernel@vger.kernel.org>
Subject: Re: Getting weird TPM error after rebasing my tree to
 security/next-general
Message-ID: <20190123201100.GA21074@linux.intel.com>
References: <20190118142559.GA4080@linux.intel.com>
 <1547849358.2794.90.camel@HansenPartnership.com>
 <20190120160413.GB30478@linux.intel.com>
 <20190122010218.GA26713@linux.intel.com>
 <20190122025836.GH25163@ziepe.ca>
 <20190122132910.GA2720@linux.intel.com>
 <CAHk-=wgdOfi+zVVfKDDqJMs2Y7Lq0uufmP8Hx8JzQFA9UzNrBw@mail.gmail.com>
 <20190123153638.GA8727@linux.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20190123153638.GA8727@linux.intel.com>
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, Jan 23, 2019 at 05:36:38PM +0200, Jarkko Sakkinen wrote:
> On Wed, Jan 23, 2019 at 07:26:42AM +1300, Linus Torvalds wrote:
> > On Wed, Jan 23, 2019 at 2:29 AM Jarkko Sakkinen
> > <jarkko.sakkinen@linux.intel.com> wrote:
> > >
> > > > >
> > > > > Fails on commit 170d13ca3a2fdaaa0283399247631b76b441cca2. Still works on
> > > > > preceding commit a959dc88f9c8900296ccf13e2f3e1cbc555a8917.
> > > >
> > > > This changes the IO access pattern in memcpy_to/fromio.. Presumably
> > > > CRB HW doesn't like the new 4 byte move? Swap each one in crb to
> > > > memcpy to confirm..
> > > >
> > > > If the HW requires particular access patterns you can't use
> > > > memcpy_to/fromio
> > >
> > > Did not have time to look at the commit at all but your deduction
> > > is correct. I know it without testing.
> > >
> > > Memory controller will feed 1's on unaligned read from IO memory,
> > > and as we can see from the TPM header, this change causes two of
> > > those:
> > 
> > Funky. But how did it work before then?
> > 
> > The new memcpy_fromio() is designed to have _predictable_ access
> > patterns. Not necessarily the best, but at least consistent.
> > 
> > Prevously, we used whatever random "memcpy()" implementation we
> > happened to pick, which *could* be aligned (particularly "rep movsb" -
> > absolutely horrible performance for MMIO, but by doing IO one byte at
> > a time it was certainly aligned ;), but most of our x86 memcpy
> > implementations don't actually try all that hard to align the source.
> > And the manual version will actually copy things *backwards* for some
> > cases.
> > 
> > Is it just that this particular hardware always happened to trigger
> > the ERMS case (ie "rep movsb")?
> 
> This is the particular snippet in question:
> 
> memcpy_fromio(buf, priv->rsp, 6);
> expected = be32_to_cpup((__be32 *) &buf[2]);
> if (expected > count || expected < 6)
> 	return -EIO;
> 
> memcpy_fromio(&buf[6], &priv->rsp[6], expected - 6);
> 
> I guess it did in the first memcpy_fromio operation since it is less
> than a quad word, right? Not sure why the 2nd memcpy_fromio() operation
> has worked, though.

And I wonder why 32-bit has worked before.

Tomas, you've been more involved with ME and fTPM runs there. Do you
have any clues where this could be rooted?

/Jarkko