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;
MIME-Version: 1.0
References: <20190826081752.57258-1-kkamagui@gmail.com> <CACdnJutomLNthYDzEc0wFBcBHK5iqnk0p-hkAkp57zQZ38oGPA@mail.gmail.com>
 <20190827124707.yhqtaqa4ur6i45h7@linux.intel.com>
In-Reply-To: <20190827124707.yhqtaqa4ur6i45h7@linux.intel.com>
From:   Seunghun Han <kkamagui@gmail.com>
Date:   Wed, 28 Aug 2019 00:49:26 +0900
Message-ID: <CAHjaAcT_9Rgbb2P29vfGjq49jLnsBXZtuJi7Ae4doD36abWFZg@mail.gmail.com>
Subject: Re: [PATCH] x86: tpm: Remove a busy bit of the NVS area for
 supporting AMD's fTPM
To:     Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Cc:     Matthew Garrett <mjg59@google.com>,
        Matthew Garrett <mjg59@srcf.ucam.org>,
        Peter Huewe <peterhuewe@gmx.de>,
        "open list:TPM DEVICE DRIVER" <linux-integrity@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

>
> On Mon, Aug 26, 2019 at 10:40:25AM -0700, Matthew Garrett wrote:
> > On Mon, Aug 26, 2019 at 1:18 AM Seunghun Han <kkamagui@gmail.com> wrote:
> > > To support AMD's fTPM, I removed the busy bit from the ACPI NVS area like
> > > the reserved area so that AMD's fTPM regions could be assigned in it.
> >
> > drivers/acpi/nvs.c saves and restores the contents of NVS regions, and
> > if other drivers use these regions without any awareness of this then
> > things may break. I'm reluctant to say that just unilaterally marking
> > these regions as available is a good thing, but it's clearly what's
> > expected by AMD's implementation. One approach would be to have a
> > callback into the nvs code to indicate that a certain region should be
> > handed off to a driver, which would ensure that we can handle this on
> > a case by case basis?
>
> What if E820 would just have a small piece of code just for fTPM's e.g.
> it would check the ACPI tree for fTPM's and ignore TPM regions.
>
> /Jarkko

It seems that it is possible. However, the memory layout is set by
enumerating e820 table and ACPI table in order, and the memory regions
are typically added and overlapped to the existing memory layout. I
also worry about the direct interaction between the e820 table and
ACPI table. As I know, they have no straightforward interface or
relationship. So, if we make the code for identifying fTPM regions in
ACPI table and write it to e820 code, we would meet other problems
like "acpi=off" kernel option.

In my view, it is natural that ACPI NVS allows device drivers to
assign some regions in it if the hardware reports the regions there.

Seunghun