From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: Harlan Lieberman-Berg <harlan@dds.mil>
Cc: Peter Huewe <peterhuewe@gmx.de>,
linux-integrity@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org
Subject: Re: Fwd: PROBLEM: tpm_cpg can't request region with AMD/Dell fTPM
Date: Sat, 11 Aug 2018 00:44:48 +0300 [thread overview]
Message-ID: <20180810214433.GA15044@linux.intel.com> (raw)
In-Reply-To: <20180810165735.GT4692@linux.intel.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: jarkko.sakkinen@linux.intel.com (Jarkko Sakkinen)
To: linux-security-module@vger.kernel.org
Subject: Fwd: PROBLEM: tpm_cpg can't request region with AMD/Dell fTPM
Date: Sat, 11 Aug 2018 00:44:48 +0300 [thread overview]
Message-ID: <20180810214433.GA15044@linux.intel.com> (raw)
In-Reply-To: <20180810165735.GT4692@linux.intel.com>
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
next prev parent reply other threads:[~2018-08-11 0:16 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAO-sURTngN_mnpJp9rvutpDfz80Nq4K8JOH4fnZG2NaTafkx+g@mail.gmail.com>
2018-08-07 18:43 ` Fwd: PROBLEM: tpm_cpg can't request region with AMD/Dell fTPM Harlan Lieberman-Berg
2018-08-10 16:57 ` Jarkko Sakkinen
2018-08-10 21:44 ` Jarkko Sakkinen [this message]
2018-08-10 21:44 ` Jarkko Sakkinen
2018-08-11 9:42 ` Tomas Winkler
2018-08-11 9:42 ` Tomas Winkler
2018-08-11 18:29 ` Harlan Lieberman-Berg
2018-08-11 18:29 ` Harlan Lieberman-Berg
2018-08-15 18:02 ` Harlan Lieberman-Berg
2018-08-15 18:02 ` Harlan Lieberman-Berg
Reply instructions:
You may reply publicly 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=20180810214433.GA15044@linux.intel.com \
--to=jarkko.sakkinen@linux.intel.com \
--cc=harlan@dds.mil \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=peterhuewe@gmx.de \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.