[PATCH] tpm_crb - workaround broken ACPI tables

From: "Safford, David (GE Global Research, US)" <david.safford@ge.com>
To: Matthew Garrett <mjg59@google.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>,
	"linux-integrity@vger.kernel.org"
	<linux-integrity@vger.kernel.org>,
	"jarkko.sakkinen@linux.intel.com"
	<jarkko.sakkinen@linux.intel.com>,
	"Wiseman, Monty (GE Global Research, US)" <monty.wiseman@ge.com>
Subject: [PATCH] tpm_crb - workaround broken ACPI tables
Date: Fri, 12 Jul 2019 12:41:58 +0000	[thread overview]
Message-ID: <BCA04D5D9A3B764C9B7405BBA4D4A3C035EF7E2A@ALPMBAPA12.e2k.ad.ge.com> (raw)
In-Reply-To: <CACdnJutS4-N0GgtYPy9GGJ8dVf48VZGF5AFL2raB55bSPKUpNw@mail.gmail.com>

> The issue is that the CRB region is mapped into a region marked as ACPI NVS.
> drivers/acpi/nvs.c claims this region and as a result a resource conflict is
> generated. Since Windows is clearly fine with other drivers using ACPI NVS
> regions, the correct fix involves figuring out a way to either share these
> resources or allow tpm_crb to reclaim the region from the NVS driver. Note
> that the NVS driver's behaviour is to save and restore NVS regions over
> suspend/resume, so simply forcibly allocating the resource will result in two
> separate codepaths touching the region on resume - this seems like a bad
> outcome. Ideally this could be solved generically, but practically (given we've
> only seen this around TPMs, as far as I can tell) adding a hook to nvs.c that
> allowed drivers aware of the issue to have the space handed off to them
> might be easier.
> 
> Have you seen this on any non-AMD systems?

Thanks - that was very helpful.
All of my misbehaving systems are AMD - mostly Ryzen and Threadripper towers,
of various motherboard OEMs. One system is a 3rd gen Ryzen laptop (Asus FX505dy).

Interestingly, all of the towers show the situation you describe:
[    1.760855] tpm_crb MSFT0101:00: can't request region for resource 
[mem 0x78edf000-0x78edffff]
[    1.760856] tpm_crb: probe of MSFT0101:00 failed with error -16
[    1.884540] ima: No TPM chip found, activating TPM-bypass!

78ab6000-78efafff : ACPI Non-volatile Storage
  78edb000-78edbfff : MSFT0101:00
  78edf000-78edffff : MSFT0101:00
78efb000-79cfcfff : Reserved

But the laptop shows a new layout:
[    2.069539] tpm_crb MSFT0101:00: can't request region for resource 
[mem 0xbd11f000-0xbd122fff]
[    2.069543] tpm_crb: probe of MSFT0101:00 failed with error -16
[    2.177663] ima: No TPM chip found, activating TPM-bypass!

bbc64000-bd14afff : Reserved
  bd11f000-bd11ffff : MSFT0101:00
  bd123000-bd123fff : MSFT0101:00
bd14b000-bd179fff : ACPI Tables
bd17a000-bd328fff : ACPI Non-volatile Storage

I never suspend/resume the towers, and apparently therefore avoid
ACPI-NVS mayhem. On the laptop, I suspend and resume all the time,
and apparently have no conflict as the region is not labeled ACPI-NVS.

Have you looked at the sequencing during suspend/restore?
If ACPI is the last to save, and first to restore, the TPM's use may
still be safe. I'll try to run some tests along those lines, and look
at the nvs driver.

thanks,
dave