On Tue, Jun 02, 2015 at 09:22:40AM -0400, Stefan Berger wrote: > On 06/02/2015 05:15 AM, Michael S. Tsirkin wrote: > >On Mon, Jun 01, 2015 at 11:11:26PM -0400, Stefan Berger wrote: > >>On 05/31/2015 02:11 PM, Michael S. Tsirkin wrote: > >>>On Tue, May 26, 2015 at 05:33:41PM -0400, Stefan Berger wrote: > >>>>For automated management of a TPM device, implement the TCG Physical > >>>>Presence > >>>>Interface Specification that allows a root user on Linux (for example) to > >>>>set > >>>>an opcode for a sequence of TPM operations that the BIOS is supposed to > >>>>execute > >>>>upon reboot of the physical or virtual machine. A sequence of operations > >>>>may for > >>>>example involve giving up ownership of the TPM and activating and > >>>>enabling the > >>>>device. > >>>> > >>>>The sequences of operations are defined in table 2 in the specs to be > >>>>found > >>>>at the following link: > >>>> > >>>>http://www.trustedcomputinggroup.org/resources/tcg_physical_presence_interface_specification > >>>> > >>>>As an example, in recent versions of Linux the opcode (5) can be set as > >>>>follows: > >>>> > >>>>cd /sys/devices/pnp0/00\:04/ppi > >>>> > >>>>echo 5 > request > >>>> > >>>>This ACPI implementation assumes that the underlying firmware (SeaBIOS) > >>>>has 'thrown an anchor' into the f-segment. The anchor is identified by > >>>>two signatures (TCG_MAGIC) surrounding a 64bit pointer. The structure > >>>>in the f-segment is write-protected and holds a pointer to a structure > >>>>in high memmory > >>>memory > >>> > >>>>area where the ACPI code writes the opcode into and > >>>>where it can read the last response from the BIOS. > >>>> > >>>>The supported opcodes are 1-11, 14, and 21-22. (see table 2 in spec) > >>>>Also '0' is supported to 'clear' an intention. > >>>> > >>>> > >>>No need for 2 empty spaces. > >>> > >>>>Signed-off-by: Stefan Berger <stef...@linux.vnet.ibm.com> > >>>>Cc: Michael Tsirkin <m...@redhat.com> > >>>>Cc: Kevin O'Connor <ke...@koconnor.net> > >>>All this seems somewhat messy. Is this FSEG trick what the spec says, > >>>or is this a QEMU specific protocol? > >>Actually, the text in the patch is outdated. We now moved the area where the > >>data are exchanged between ACPI and BIOS into registers provided by the TIS > >>-- custom registers in an area that is vendor-specific, so yes, this is a > >>QEMU specific solution. The address range for this is fixed and known to > >>SeaBIOS and QEMU. Those registers also won't reset upon machine reboot. > >Hmm. One way to do a machine reboot is to exit QEMU > >then restart it. Where do these registers persist? > > > They won't persist. If one powers down the physical machine, this won't work > or not that I would know of that it would have to work. > > > > > >>>Would DataTableRegion not be a better way to locate things in > >>>memory? > >>As I said, we now move that into a memory region provide by the TIS.. > >>Otherwise I am not very familiar with DataTableRegion. > >> > >>Thanks for the comments! > >> > >> Stefan > >A data table is a structure that you define (as opposed to code). > >Using linker you can allocate some memory and put a pointer > >there, then use DataTableRegion to read that pointer value. > > > > How would the BIOS then find that memory (so it can read the command code > and act on it)? Would it need to walk ACPI tables or how would it find the > base address? > > Stefan
This is similar to things like suspend/resume. The bios walks the list of the tables RSDP->XSDT, and locates the data table either by triple signature/vendorid/vendortableid, or by detecting a UEFI signature and locating the matching GUID (second option is preferable given current OVMF code). -- MST
