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

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

[Harlan Lieberman-Berg]

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

Hello maintainers,

When attempting to setup the TPM 2.0 firmware TPM built into the Dell
Inspiron 11 3180, it does not show up in /dev nor does it show up in
/sys/class/tpm.  An inspection of dmesg shows the following error:

[    6.359382] tpm_crb MSFT0101:00: can't request region for resource
[mem 0xe7bba000-0xe7bbdfff]
[    6.359430] tpm_crb: probe of MSFT0101:00 failed with error -16

I have tested both on kernel version 4.17.0-1 and 4.18.0-rc4, both
x86_64, and they have shown the same error.  Similarly, I have tested
with both the 1.1.0 and 1.3.0 versions of the underlying firmware.

The Dell Inspiron 11 3180 has the following cpuinfo (trimmed for brevity):

processor    : 1
vendor_id    : AuthenticAMD
cpu family    : 21
model        : 112
model name    : AMD A6-9220e RADEON R4, 5 COMPUTE CORES 2C+3G
stepping    : 0
microcode    : 0x6006704
cpu MHz        : 1367.077
cache size    : 1024 KB
physical id    : 0
siblings    : 2
core id        : 1
cpu cores    : 2
apicid        : 17
initial apicid    : 1
fpu        : yes
fpu_exception    : yes
cpuid level    : 13
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext
fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good acc_power nopl
nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3
fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm
cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch
osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm perfctr_core
perfctr_nb bpext ptsc mwaitx cpb hw_pstate ssbd vmmcall fsgsbase bmi1
avx2 smep bmi2 xsaveopt arat npt lbrv svm_lock nrip_save tsc_scale
vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic
v_vmsave_vmload vgif overflow_recov
bugs        : fxsave_leak sysret_ss_attrs null_seg spectre_v1
spectre_v2 spec_store_bypass
bogomips    : 3193.84
TLB size    : 1536 4K pages
clflush size    : 64
cache_alignment    : 64
address sizes    : 48 bits physical, 48 bits virtual
power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro acc_power [13]

The ver_linux output:

Linux brick 4.18.0-rc4-amd64 #1 SMP Debian 4.18~rc4-1~exp1
(2018-07-12) x86_64 GNU/Linux

GNU Make                4.2.1
Binutils                2.31.1
Util-linux              2.32
Mount                   2.32
Linux C Library         2.27
Dynamic linker (ldd)    2.27
Procps                  3.3.15
Kbd                     2.0.4
Console-tools           2.0.4
Sh-utils                8.28
Udev                    239
Modules Loaded          ac acpi_cpufreq aesni_intel aes_x86_64 af_alg
ahci algif_skcipher amdgpu amdkfd ansi_cprng arc4 ath ath3k ath9k
ath9k_common ath9k_hw autofs4 battery bluetooth bnep btbcm btintel
btrtl btusb button ccp cfg80211 chash crc16 crc32c_generic
crc32c_intel crc32_pclmul crct10dif_pclmul cryptd crypto_simd dcdbas
dell_laptop dell_rbtn dell_smbios dell_smm_hwmon dell_wmi
dell_wmi_descriptor dm_crypt dm_mod drbg drm drm_kms_helper ecb
ecdh_generic edac_mce_amd efi_pstore efivarfs efivars ehci_hcd
ehci_pci evdev ext4 fam15h_power fat fscrypto fuse ghash_clmulni_intel
glue_helper gpu_sched hid i2c_algo_bit i2c_hid i2c_piix4 ip_tables
irqbypass jbd2 jitterentropy_rng joydev k10temp kvm kvm_amd libahci
libata lp mac80211 mbcache media memstick mmc_core nls_ascii nls_cp437
parport parport_pc pcbc pcspkr ppdev psmouse rfkill rng_core rtsx_usb
rtsx_usb_ms rtsx_usb_sdmmc scsi_mod sd_mod serio_raw sg snd
snd_hda_codec snd_hda_codec_generic snd_hda_codec_hdmi
snd_hda_codec_realtek snd_hda_core snd_hda_intel snd_hwdep snd_pcm
snd_timer soundcore sp5100_tco sparse_keymap thermal tpm tpm_crb
tpm_tis tpm_tis_core ttm usb_common usbcore uvcvideo vfat video
videobuf2_common videobuf2_memops videobuf2_v4l2 videobuf2_vmalloc
videodev wmi wmi_bmof xhci_hcd xhci_pci x_tables

The ioports, iomem, lspci, and acpidump are located at
https://gist.github.com/hlieberman-gov/a718cf4aff8aa701e10eb37162bb943f.
I am happy to help debug this however is needed.

Sincerely,
--
Harlan Lieberman-Berg
Defense Digital Service

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

[Jarkko Sakkinen]

On Tue, Aug 07, 2018 at 02:43:10PM -0400, Harlan Lieberman-Berg wrote:
> (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.

/Jarkko

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

[Jarkko Sakkinen]

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:
> > (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
Could not get ACPI tables from dsdt.dat, AE_BAD_HEADER

This has not happened to me before.

/Jarkko

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

[Jarkko Sakkinen]

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:
> > (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
Could not get ACPI tables from dsdt.dat, AE_BAD_HEADER

This has not happened to me before.

/Jarkko

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

[Tomas Winkler]

On Sat, Aug 11, 2018 at 12:45 AM Jarkko Sakkinen
<jarkko.sakkinen@linux.intel.com> wrote:
>
> 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:
> > > (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
> Could not get ACPI tables from dsdt.dat, AE_BAD_HEADER
>
> This has not happened to me before.
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

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

[Tomas Winkler]

On Sat, Aug 11, 2018 at 12:45 AM Jarkko Sakkinen
<jarkko.sakkinen@linux.intel.com> wrote:
>
> 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:
> > > (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
> Could not get ACPI tables from dsdt.dat, AE_BAD_HEADER
>
> This has not happened to me before.
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

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

[Harlan Lieberman-Berg]

On Sat, Aug 11, 2018 at 5:42 AM, Tomas Winkler <tomasw@gmail.com> 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

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

[Harlan Lieberman-Berg]

On Sat, Aug 11, 2018 at 5:42 AM, Tomas Winkler <tomasw@gmail.com> 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

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

[Harlan Lieberman-Berg]

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

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

[Harlan Lieberman-Berg]

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