Re: Fwd: PROBLEM: tpm_cpg can't request region with AMD/Dell fTPM

On Fri, Aug 10, 2018 at 07:57:35PM +0300, Jarkko Sakkinen wrote:

On Tue, Aug 07, 2018 at 02:43:10PM -0400, Harlan Lieberman-Berg wrote:

quoted

(Resending as it seems to have been spamfiltered out from the ml;
sorry Peter, Jarkko for the duplicate)

I came on Monday from four week leave and have been basically been
catching up with my emails :-) I'll look into this next week with
time.

The error message is saying that someone else has reserved the resource
(-EBUSY).

This looks odd:

e78bf000-e7bbefff : ACPI Non-volatile Storage
  e7bb6000-e7bb9fff : MSFT0101:00
  e7bba000-e7bbdfff : MSFT0101:00

Why would be TPM registers mapped inside ACPI NV?

I would *guess* that what is happening is that perhaps drivers/acpi/nvs.c
maps the address space. This looks like a firmware bug, and such that we
cannot do anything about it.

I'm having a weird issue with the ACPI tables:

$ acpixtract acpidump.txt

Intel ACPI Component Architecture
ACPI Binary Table Extraction Utility version 20180105
Copyright (c) 2000 - 2018 Intel Corporation

  DSDT -   31048 bytes written (0x00007948) - dsdt.dat
  SSDT -     349 bytes written (0x0000015D) - ssdt1.dat
  SSDT -   18086 bytes written (0x000046A6) - ssdt2.dat
  SSDT -    5225 bytes written (0x00001469) - ssdt3.dat
  SSDT -    1082 bytes written (0x0000043A) - ssdt4.dat
  SSDT -    1017 bytes written (0x000003F9) - ssdt5.dat
  SSDT -    5369 bytes written (0x000014F9) - ssdt6.dat

$ iasl -d *.dat   

Intel ACPI Component Architecture
ASL+ Optimizing Compiler/Disassembler version 20180105
Copyright (c) 2000 - 2018 Intel Corporation

Input file dsdt.dat, Length 0x7948 (31048) bytes
Table [DSDT] is too long for file - needs: 0x815D, remaining in file: 0x7948

5 more lines

On Sat, Aug 11, 2018 at 12:45 AM Jarkko Sakkinen
[off-list ref] wrote:

On Fri, Aug 10, 2018 at 07:57:35PM +0300, Jarkko Sakkinen wrote:

quoted

On Tue, Aug 07, 2018 at 02:43:10PM -0400, Harlan Lieberman-Berg wrote:

quoted

(Resending as it seems to have been spamfiltered out from the ml;
sorry Peter, Jarkko for the duplicate)

I came on Monday from four week leave and have been basically been
catching up with my emails :-) I'll look into this next week with
time.

The error message is saying that someone else has reserved the resource
(-EBUSY).

This looks odd:

e78bf000-e7bbefff : ACPI Non-volatile Storage
  e7bb6000-e7bb9fff : MSFT0101:00
  e7bba000-e7bbdfff : MSFT0101:00

Why would be TPM registers mapped inside ACPI NV?

I would *guess* that what is happening is that perhaps drivers/acpi/nvs.c
maps the address space. This looks like a firmware bug, and such that we
cannot do anything about it.

I'm having a weird issue with the ACPI tables:

$ acpixtract acpidump.txt

Intel ACPI Component Architecture
ACPI Binary Table Extraction Utility version 20180105
Copyright (c) 2000 - 2018 Intel Corporation

  DSDT -   31048 bytes written (0x00007948) - dsdt.dat
  SSDT -     349 bytes written (0x0000015D) - ssdt1.dat
  SSDT -   18086 bytes written (0x000046A6) - ssdt2.dat
  SSDT -    5225 bytes written (0x00001469) - ssdt3.dat
  SSDT -    1082 bytes written (0x0000043A) - ssdt4.dat
  SSDT -    1017 bytes written (0x000003F9) - ssdt5.dat
  SSDT -    5369 bytes written (0x000014F9) - ssdt6.dat

12 more quoted lines

What platform is this? This is not regular 0xfed40000 address space. I
guess this is BYT or CHT.  It's better to get dmideoce dump as well.
It looks more like a BIOS issue.
Please forward the complete data.
Thanks
Tomas

On Sat, Aug 11, 2018 at 5:42 AM, Tomas Winkler [off-list ref] wrote:

What platform is this? This is not regular 0xfed40000 address space. I
guess this is BYT or CHT.  It's better to get dmideoce dump as well.

Hello Tomas, Jarkko, all,

I'm not sure what's up with that.  I've updated the firmware to the
latest version (with no fix, sadly), and re-dumped the ACPI tables.
They now process correctly through isl v20180629.  I've also saved the
output of dmidecode for you.

https://gist.github.com/hlieberman-gov/83fa708d41051bafccc553cf0147db4f

Sincerely,
-- 
Harlan Lieberman-Berg
Defense Digital Service

Hello all,

Just wanted to give you a quick update now that I got my hands on an
OEM Windows version of the same machine.  I can confirm that Windows
is able to use the TPM to some extent; confirmation and some of the
output of some of the TPM Powershell cmdlets is at
https://gist.github.com/hlieberman-gov/915fda005e3297570e9e6e68e1708bc6

Sincerely,

-- 
Harlan Lieberman-Berg
Defense Digital Service