Re: investigating TPM for OVMF-on-QEMU

[Laszlo Ersek <lersek@redhat.com>]

On 07/14/17 22:30, Peter Jones wrote:
> On Fri, Jul 14, 2017 at 08:04:14PM +0200, Laszlo Ersek wrote:

>> (2e) Modules that we should use. Again, in increasing order of
>>      dependence. And here I'll comment as well on what these do:
>>
>>        Tcg2Config/Tcg2ConfigPei.inf -- Informs the firmware globally
>>                                        about the TPM device type. This
>>                                        module can perform device
>>                                        detection or read a cached value
>>                                        from a non-volatile UEFI
>>                                        variable.
>>
>>        Tcg2Pei/Tcg2Pei.inf          -- Initializes the TPM device and
>>                                        measures the firmware volumes in
>>                                        the PEI phase into the TPM's
>>                                        platform config registers.
>>
>>        Tcg2Dxe/Tcg2Dxe.inf          -- Measures DXE phase (and later)
>>                                        modules into the TPM's PCRs, and
>>                                        also lets the OS boot loader
>>                                        measure things, by exposing the
>>                                        EFI_TCG2_PROTOCOL.
>>
>>        Tcg2Config/Tcg2ConfigDxe.inf -- Provides a Setup TUI interface to
>>                                        configure the TPM. IIUC, it can
>>                                        also save the configured TPM type
>>                                        for subsequent boots (see
>>                                        Tcg2ConfigPei.inf above).
>>
>>      This driver stack supports the TIS (MMIO) hardware interface, which
>>      is advertized to the OS in the TPM2 ACPI Table's "start method"
>>      field with value 6. (The according macro is TPM2_START_METHOD_MMIO
>>      in the QEMU source code, and EFI_TPM2_ACPI_TABLE_START_METHOD_TIS
>>      in the edk2 source code.)
>>
>>      Including these drivers should result in a functional
>>      EFI_TCG2_PROTOCOL, which is what OS boot loaders primarily care
>>      about, as I understand.
>>
>>      Importantly, the driver stack above requires PEI-phase variable
>>      access, therefore
>>      <https://bugzilla.tianocore.org/show_bug.cgi?id=386> must be solved
>>      first.
>>
>>      (I have had patches for said BZ ready for a while. I've failed to
>>      upstream them thus far because a pflash-based varstore is a hard
>>      requirement for them. I think that's a natural requirement, but
>>      thus far my arguments haven't proved compelling enough.)
>
> It does seem pretty natural... what's the counter argument?

Jordan holds the opinion that "we should continue to support the memory
vars, even if they have some obvious drawbacks":

http://mid.mail-archive.com/149065122031.28789.9113394760317457361@jljusten-skl

I'm of a different opinion: while I agree that we should not break the
existing memory emulation, I'm also convinced that we should not develop
new features for it, especially when a new feature (such as PEI-phase
R/O variable access) simply cannot be *sensibly* extended to said
emulation.

Please see the first discussion under my original patch set:

http://mid.mail-archive.com/148969026858.27582.5519307275216644796@jljusten-skl.jf.intel.com
http://mid.mail-archive.com/319ff8f1-4e99-f977-5c2e-75509a222706@redhat.com
http://mid.mail-archive.com/c20c6604-2153-aa57-cee5-24089a79b1e9@redhat.com
http://mid.mail-archive.com/149034108785.2439.14733776608486243050@jljusten-skl
http://mid.mail-archive.com/4b06b195-d8fb-a33e-3492-74fe396ebf6e@redhat.com

And the second discussion under Jordan's counter-proposal:

http://mid.mail-archive.com/a12bbf61-3f55-2fda-b855-58aeb99a4f42@redhat.com
http://mid.mail-archive.com/149065122031.28789.9113394760317457361@jljusten-skl
http://mid.mail-archive.com/121bb81b-08d1-d854-cf6f-ebc8268eb360@redhat.com
http://mid.mail-archive.com/149076505135.12962.12298731900768295093@jljusten-skl

Thanks
Laszlo