linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Safford, David (GE Global Research, US)" <david.safford@ge.com>
To: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
	Seunghun Han <kkamagui@gmail.com>
Cc: Peter Huewe <peterhuewe@gmx.de>,
	Thomas Gleixner <tglx@linutronix.de>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-integrity@vger.kernel.org"
	<linux-integrity@vger.kernel.org>
Subject: [PATCH] tpm: tpm_crb: Add an AMD fTPM support feature
Date: Mon, 26 Aug 2019 11:58:40 +0000	[thread overview]
Message-ID: <BCA04D5D9A3B764C9B7405BBA4D4A3C035F1BAA7@ALPMBAPA12.e2k.ad.ge.com> (raw)
In-Reply-To: <20190826055903.5um5pfweoszibem3@linux.intel.com>

> From: linux-integrity-owner@vger.kernel.org <linux-integrity-
> owner@vger.kernel.org> On Behalf Of Jarkko Sakkinen
> Sent: Monday, August 26, 2019 1:59 AM
> To: Seunghun Han <kkamagui@gmail.com>
> Cc: Peter Huewe <peterhuewe@gmx.de>; Thomas Gleixner
> <tglx@linutronix.de>; linux-kernel@vger.kernel.org; linux-
> integrity@vger.kernel.org
> Subject: EXT: Re: [PATCH] tpm: tpm_crb: Add an AMD fTPM support feature
> 
> On Mon, Aug 26, 2019 at 02:40:19AM +0900, Seunghun Han wrote:
> > I'm Seunghun Han and work at the Affiliated Institute of ETRI. I got
> > an AMD system which had a Ryzen Threadripper 1950X and MSI mainboard,
> > and I had a problem with AMD's fTPM. My machine showed an error
> > message below, and the fTPM didn't work because of it.
> >
> > [    5.732084] tpm_crb MSFT0101:00: can't request region for resource
> >                [mem 0x79b4f000-0x79b4ffff]
> > [    5.732089] tpm_crb: probe of MSFT0101:00 failed with error -16
> >
> > When I saw the iomem areas and found two TPM CRB regions were in the
> > ACPI NVS area.  The iomem regions are below.
> >
> > 79a39000-79b6afff : ACPI Non-volatile Storage
> >   79b4b000-79b4bfff : MSFT0101:00
> >   79b4f000-79b4ffff : MSFT0101:00
> >
> > After analyzing this issue, I found out that a busy bit was set to the
> > ACPI NVS area, and the current Linux kernel allowed nothing to be
> > assigned in it. I also found that the kernel couldn't calculate the
> > sizes of command and response buffers correctly when the TPM regions
> were two or more.
> >
> > To support AMD's fTPM, I removed the busy bit from the ACPI NVS area
> > so that AMD's fTPM regions could be assigned in it. I also fixed the
> > bug that did not calculate the sizes of command and response buffer
> correctly.

The problem is that the acpi tables are _wrong_ in this and other cases.
They not only incorrectly report the area as reserved, but also report
the command and response buffer sizes incorrectly. If you look at
the addresses for the buffers listed in the crb control area, the sizes
are correct (4Kbytes).  My patch uses the control area values, and
everything works. The remaining problem is that if acpi reports the
area as NVS, then the linux nvs driver will try to use the space.
I'm looking at how to fix that. I'm not sure, if simply removing
the busy bit is sufficient.
Dave

> >
> > Signed-off-by: Seunghun Han <kkamagui@gmail.com>
> 
> You need to split this into multiple patches e.g. if you think you've fixed a
> bug, please write a patch with just the bug fix and nothing else.
> 
> For further information, read the section three of
> 
> https://www.kernel.org/doc/html/latest/process/submitting-patches.html
> 
> I'd also recommend to check out the earlier discussion on ACPI NVS:
> 
> https://lore.kernel.org/linux-
> integrity/BCA04D5D9A3B764C9B7405BBA4D4A3C035EF7BC7@ALPMBAPA12.e
> 2k.ad.ge.com/
> 
> /Jarkko

  parent reply	other threads:[~2019-08-26 12:44 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-25 17:40 [PATCH] tpm: tpm_crb: Add an AMD fTPM support feature Seunghun Han
2019-08-26  5:59 ` Jarkko Sakkinen
2019-08-26  9:12   ` Seunghun Han
2019-08-26 11:58   ` Safford, David (GE Global Research, US) [this message]
2019-08-27  7:38     ` Seunghun Han

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BCA04D5D9A3B764C9B7405BBA4D4A3C035F1BAA7@ALPMBAPA12.e2k.ad.ge.com \
    --to=david.safford@ge.com \
    --cc=jarkko.sakkinen@linux.intel.com \
    --cc=kkamagui@gmail.com \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterhuewe@gmx.de \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).