qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v3 3/4] acpi: build TPM Physical Presence interf


From: Stefan Berger
Subject: Re: [Qemu-devel] [PATCH v3 3/4] acpi: build TPM Physical Presence interface
Date: Thu, 21 Jun 2018 09:48:40 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0

On 06/21/2018 09:21 AM, Marc-André Lureau wrote:
Hi

On Thu, Jun 21, 2018 at 2:54 PM, Igor Mammedov <address@hidden> wrote:
On Tue, 15 May 2018 14:14:32 +0200
Marc-André Lureau <address@hidden> wrote:

From: Stefan Berger <address@hidden>

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 <address@hidden>

---

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
---


 From ACPI pov I'd prefer PPI table documented somewhere in spec docs
(similar docs/specs/acpi_mem_hotplug.txt) and would look like in
other use-cases:

    aml_append(field, aml_named_field("PPIN", 8)

and drop "struct tpm_ppi" altogether replacing places it was used by
explicit constants.
I have a slight preference for the tpm_ppi structure. But ok with
replacing it with constant. Stefan, do you agree?

The PPI structure will appear in the firmware code and if it is the same and is correctly used we know that both are in sync. So I wouldn't get rid of it based on just that. If we have to changed all sizeof(uint32_t/uint8_t) to correctly use that shared structure, I'd prefer that.

    Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]