From: Stefan Berger <stefanb@linux.vnet.ibm.com>
To: "Marc-André Lureau" <marcandre.lureau@gmail.com>,
"Igor Mammedov" <imammedo@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
QEMU <qemu-devel@nongnu.org>, Paolo Bonzini <pbonzini@redhat.com>,
Richard Henderson <rth@twiddle.net>
Subject: Re: [Qemu-devel] [PATCH v3 3/4] acpi: build TPM Physical Presence interface
Date: Thu, 21 Jun 2018 13:36:51 -0400 [thread overview]
Message-ID: <d9c2a9b5-4dd8-2f2c-86db-53bbad62efac@linux.vnet.ibm.com> (raw)
In-Reply-To: <CAJ+F1CLHtrx0hC9AUQ_JvvGGMx5D-X6=hy3A1c+MC0P-5Q3QAg@mail.gmail.com>
On 06/21/2018 01:10 PM, Marc-André Lureau wrote:
> Hi
>
> On Thu, Jun 21, 2018 at 4:23 PM, Igor Mammedov <imammedo@redhat.com> wrote:
>> On Thu, 21 Jun 2018 15:21:02 +0200
>> Marc-André Lureau <marcandre.lureau@gmail.com> wrote:
>>
>>> Hi
>>>
>>> On Thu, Jun 21, 2018 at 2:54 PM, Igor Mammedov <imammedo@redhat.com> wrote:
>>>> On Tue, 15 May 2018 14:14:32 +0200
>>>> Marc-André Lureau <marcandre.lureau@redhat.com> wrote:
>>>>
>>>>> From: Stefan Berger <stefanb@linux.vnet.ibm.com>
>>>>>
>>>>> The TPM Physical Presence interface consists of an ACPI part, a shared
>>>>> memory part, and code in the firmware. Users can send messages to the
>>>>> firmware by writing a code into the shared memory through invoking the
>>>>> ACPI code. When a reboot happens, the firmware looks for the code and
>>>>> acts on it by sending sequences of commands to the TPM.
>>>>>
>>>>> This patch adds the ACPI code. It is similar to the one in EDK2 but doesn't
>>>>> assume that SMIs are necessary to use. It uses a similar datastructure for
>>>>> the shared memory as EDK2 does so that EDK2 and SeaBIOS could both make use
>>>>> of it. I extended the shared memory data structure with an array of 256
>>>>> bytes, one for each code that could be implemented. The array contains
>>>>> flags describing the individual codes. This decouples the ACPI implementation
>>>>> from the firmware implementation.
>>>>>
>>>>> The underlying TCG specification is accessible from the following page.
>>>>>
>>>>> https://trustedcomputinggroup.org/tcg-physical-presence-interface-specification/
>>>>>
>>>>> This patch implements version 1.30.
>>>>>
>>>>> Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
>>>>>
>>>>> ---
>>>>>
>>>>> v4 (Marc-André):
>>>>> - replace 'DerefOf (FUNC [N])' with a function, to fix Windows ACPI
>>>>> handling.
>>>>> - replace 'return Package (..) {} ' with scoped variables, to fix
>>>>> Windows ACPI handling.
>>>>>
>>>>> v3:
>>>>> - add support for PPI to CRB
>>>>> - split up OperationRegion TPPI into two parts, one containing
>>>>> the registers (TPP1) and the other one the flags (TPP2); switched
>>>>> the order of the flags versus registers in the code
>>>>> - adapted ACPI code to small changes to the array of flags where
>>>>> previous flag 0 was removed and now shifting right wasn't always
>>>>> necessary anymore
>>>>>
>>>>> v2:
>>>>> - get rid of FAIL variable; function 5 was using it and always
>>>>> returns 0; the value is related to the ACPI function call not
>>>>> a possible failure of the TPM function call.
>>>>> - extend shared memory data structure with per-opcode entries
>>>>> holding flags and use those flags to determine what to return
>>>>> to caller
>>>>> - implement interface version 1.3
>>>>> ---
>>>>> include/hw/acpi/tpm.h | 21 +++
>>>>> hw/i386/acpi-build.c | 294 +++++++++++++++++++++++++++++++++++++++++-
>>>>> 2 files changed, 314 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/include/hw/acpi/tpm.h b/include/hw/acpi/tpm.h
>>>>> index f79d68a77a..fc53f08827 100644
>>>>> --- a/include/hw/acpi/tpm.h
>>>>> +++ b/include/hw/acpi/tpm.h
>>>>> @@ -196,4 +196,25 @@ REG32(CRB_DATA_BUFFER, 0x80)
>>>>> #define TPM_PPI_VERSION_NONE 0
>>>>> #define TPM_PPI_VERSION_1_30 1
>>>>>
>>>>> +struct tpm_ppi {
>>>>> + uint8_t func[256]; /* 0x000: per TPM function implementation flags;
>>>>> + set by BIOS */
>>>>> +/* whether function is blocked by BIOS settings; bits 0, 1, 2 */
>>>>> +#define TPM_PPI_FUNC_NOT_IMPLEMENTED (0 << 0)
>>>>> +#define TPM_PPI_FUNC_BIOS_ONLY (1 << 0)
>>>>> +#define TPM_PPI_FUNC_BLOCKED (2 << 0)
>>>>> +#define TPM_PPI_FUNC_ALLOWED_USR_REQ (3 << 0)
>>>>> +#define TPM_PPI_FUNC_ALLOWED_USR_NOT_REQ (4 << 0)
>>>>> +#define TPM_PPI_FUNC_MASK (7 << 0)
>>>>> + uint8_t ppin; /* 0x100 : set by BIOS */
>>>>> + uint32_t ppip; /* 0x101 : set by ACPI; not used */
>>>>> + uint32_t pprp; /* 0x105 : response from TPM; set by BIOS */
>>>>> + uint32_t pprq; /* 0x109 : opcode; set by ACPI */
>>>>> + uint32_t pprm; /* 0x10d : parameter for opcode; set by ACPI */
>>>>> + uint32_t lppr; /* 0x111 : last opcode; set by BIOS */
>>>>> + uint32_t fret; /* 0x115 : set by ACPI; not used */
>>>>> + uint8_t res1[0x40]; /* 0x119 : reserved for future use */
>>>>> + uint8_t next_step; /* 0x159 : next step after reboot; set by BIOS */
>>>>> +} QEMU_PACKED;
>>>> is this structure plant to be used for accessing data from within QEMU
>>>> or it is just used for convenience of calculating offsets/sizes for AML?
>>>>
>>>>
>>> For convenience (and it can be useful for debugging).
>> we are gradually getting rid of usage "struct foo" in ACPI code
>> (i.e. when I have time to convert old struct based approach
>> to build_append_int() table based format).
>> and for new code I usually require ACPI parts be struct less
>> (if there is no previous struct baggage to back it up).
>>
> The tpm_ppi struct is not an ACPI table, it's a fixed memory region /
> layout to exchange between guest/os and firmware.
>
>> Hence my request to drop dummy struct and document layout
>> properly in related spec doc (that's where FW should look for
>> documentation and not into struct definition somewhere in
>> the header). So I'd strongly prefer it be done this way.
> There is not much more than the field description for me ;). Stefan,
> would you like to develop the structure usage?
Will do.
next prev parent reply other threads:[~2018-06-21 17:37 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-15 12:14 [Qemu-devel] [PATCH v3 0/4] Add support for TPM Physical Presence interface Marc-André Lureau
2018-05-15 12:14 ` [Qemu-devel] [PATCH v3 1/4] tpm: implement virtual memory device for TPM PPI Marc-André Lureau
2018-05-15 14:19 ` Stefan Berger
2018-06-21 9:49 ` Igor Mammedov
2018-06-21 10:51 ` Marc-André Lureau
2018-06-21 13:59 ` Igor Mammedov
2018-05-15 12:14 ` [Qemu-devel] [PATCH v3 2/4] acpi: add fw_cfg file for TPM and PPI virtual memory device Marc-André Lureau
2018-06-21 10:00 ` Igor Mammedov
2018-06-21 10:10 ` Marc-André Lureau
2018-06-21 13:55 ` Igor Mammedov
2018-06-22 0:16 ` Laszlo Ersek
2018-06-25 15:20 ` Laszlo Ersek
2018-06-26 10:38 ` Marc-André Lureau
2018-06-26 10:54 ` Laszlo Ersek
2018-05-15 12:14 ` [Qemu-devel] [PATCH v3 3/4] acpi: build TPM Physical Presence interface Marc-André Lureau
2018-06-20 14:08 ` Michael S. Tsirkin
2018-06-20 14:35 ` Marc-André Lureau
2018-06-20 15:08 ` Laszlo Ersek
2018-06-20 15:31 ` Michael S. Tsirkin
2018-06-20 16:37 ` Stefan Berger
2018-06-21 12:54 ` Igor Mammedov
2018-06-21 13:21 ` Marc-André Lureau
2018-06-21 13:22 ` Marc-André Lureau
2018-06-21 14:13 ` Marc-André Lureau
2018-06-21 14:27 ` Igor Mammedov
2018-06-21 13:48 ` Stefan Berger
2018-06-21 14:23 ` Igor Mammedov
2018-06-21 17:10 ` Marc-André Lureau
2018-06-21 17:36 ` Stefan Berger [this message]
2018-06-22 13:40 ` Igor Mammedov
2018-05-15 12:14 ` [Qemu-devel] [PATCH v3 4/4] tpm: add a fake ACPI memory clear interface Marc-André Lureau
2018-06-21 13:02 ` Igor Mammedov
2018-06-21 13:24 ` Marc-André Lureau
2018-06-21 13:59 ` Stefan Berger
2018-06-21 14:33 ` Igor Mammedov
2018-06-26 9:22 ` Marc-André Lureau
2018-06-26 12:34 ` Igor Mammedov
2018-06-26 12:47 ` Laszlo Ersek
2018-06-26 15:22 ` Stefan Berger
2018-06-20 13:11 ` [Qemu-devel] [PATCH v3 0/4] Add support for TPM Physical Presence interface Marc-André Lureau
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=d9c2a9b5-4dd8-2f2c-86db-53bbad62efac@linux.vnet.ibm.com \
--to=stefanb@linux.vnet.ibm.com \
--cc=ehabkost@redhat.com \
--cc=imammedo@redhat.com \
--cc=marcandre.lureau@gmail.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).