Linux-Integrity Archive on lore.kernel.org
 help / color / Atom feed
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
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

  reply index

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-11 12:29 Safford, David (GE Global Research, US)
2019-07-11 14:10 ` Jarkko Sakkinen
2019-07-11 14:58 ` Jason Gunthorpe
2019-07-11 16:44   ` Safford, David (GE Global Research, US)
2019-07-11 18:50     ` Jason Gunthorpe
2019-07-11 19:31       ` Safford, David (GE Global Research, US)
2019-07-11 20:33         ` Matthew Garrett
2019-07-12 12:41           ` Safford, David (GE Global Research, US) [this message]
2019-07-12 15:06             ` Jason Gunthorpe
2019-07-12 15:48               ` Jarkko Sakkinen
2019-07-12 18:24             ` Matthew Garrett
2019-07-12 19:05               ` Safford, David (GE Global Research, US)
2019-07-12 20:36                 ` Matthew Garrett
2019-07-14 19:28                   ` Safford, David (GE Global Research, US)
2019-07-14 23:48                     ` Matthew Garrett
2019-07-15 19:44                       ` Matthew Garrett
2019-07-11 19:16 ` Jarkko Sakkinen

Reply instructions:

You may reply publically 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=BCA04D5D9A3B764C9B7405BBA4D4A3C035EF7E2A@ALPMBAPA12.e2k.ad.ge.com \
    --to=david.safford@ge.com \
    --cc=jarkko.sakkinen@linux.intel.com \
    --cc=jgg@ziepe.ca \
    --cc=linux-integrity@vger.kernel.org \
    --cc=mjg59@google.com \
    --cc=monty.wiseman@ge.com \
    /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

Linux-Integrity Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-integrity/0 linux-integrity/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-integrity linux-integrity/ https://lore.kernel.org/linux-integrity \
		linux-integrity@vger.kernel.org linux-integrity@archiver.kernel.org
	public-inbox-index linux-integrity


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-integrity


AGPL code for this site: git clone https://public-inbox.org/ public-inbox