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

[Stefan Berger]

On 01/16/2018 05:35 PM, Kevin O'Connor wrote:
> 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,

QEMU does implement the ACPI code. The firmware may implement a subset 
of what the specs are describing. The array of flags helps to decouple 
the ACPI code and the firmware and allows OVMF and SeaBIOS and possibly 
others to only implement a subset of the functionality.

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

Its SeaBIOS vor OVMF reporting to ACPI what it implements. QEMU doesn't 
know what the firmware implements.

    Stefan

>
> -Kevin
>