[SeaBIOS] [PATCH v2 2/3] tcgbios: Add TPM Physical Presence interface support

Kevin O'Connor kevin at koconnor.net
Tue Jan 16 23:35:25 CET 2018


On Tue, Jan 16, 2018 at 05:01:51PM -0500, Stefan Berger wrote:
> On 01/16/2018 01:36 PM, Kevin O'Connor wrote:
> > On Tue, Jan 16, 2018 at 11:41:02AM -0500, Stefan Berger wrote:
> > > +    tp = (struct tpm_ppi *)(u32)qemu->tpmppi_address;
> > > +    dprintf(DEBUG_tcg, "TCGBIOS: TPM PPI struct at %p\n", tp);
> > > +
> > > +    memset(&tp->func, 0, sizeof(tp->func));
> > > +    switch (qemu->tpmppi_version) {
> > > +    case TPM_PPI_VERSION_1_30:
> > > +        switch (qemu->tpm_version) {
> > > +        case TPM_VERSION_1_2:
> > > +            memcpy(&tp->func, tpm12_ppi_funcs, sizeof(tpm12_ppi_funcs));
> > > +            break;
> > > +        case TPM_VERSION_2:
> > > +            memcpy(&tp->func, tpm2_ppi_funcs, sizeof(tpm2_ppi_funcs));
> > > +            break;
> > > +        }
> > Can you elaborate on what this does?  Why is SeaBIOS filling a memory
> > addreses created by QEMU?  Why wouldn't QEMU just fill it with what it
> > wants directly?
> 
> QEMU merely creates the device and the ACPI code. SeaBIOS implements which
> codes the user can send. The above array inside the virtual device contains
> flags that describe the codes that the user can send. If OVMF was to
> implement less codes, less bytes would be set. If another firmware
> implemented the possibility to prevent the user from sending certain codes,
> the TPM_PPI_FUNC_BLOCKED flag could be set for example so that ACPI would
> refuse to set the code for the next reboot. It's parametrizing the interface
> between ACPI and firmware.

Is this the right approach?  If QEMU has all the code to emulate the
TPM hardware and QEMU has all the code to build the ACPI tables
describing that hardware - why doesn't it just implement the PPI
functions itself on a reboot?  I'll defer to Laszlo, Igor, Michael,
etc, but this seems like a complex firmware<->qemu interface and I'm
not sure I understand the gain.

The above aside, if there's a need to communicate firmware
capabilities to QEMU (so that QEMU can build the ACPI tables
describing that capability), can we reuse the writable fw_cfg file
system to transfer that information (instead of having the firmware
fill an area of memory)?

-Kevin



More information about the SeaBIOS mailing list