[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [edk2] investigating TPM for OVMF-on-QEMU
From: |
Laszlo Ersek |
Subject: |
Re: [Qemu-devel] [edk2] investigating TPM for OVMF-on-QEMU |
Date: |
Fri, 14 Jul 2017 23:31:21 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 |
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/address@hidden
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/address@hidden
http://mid.mail-archive.com/address@hidden
http://mid.mail-archive.com/address@hidden
http://mid.mail-archive.com/address@hidden
http://mid.mail-archive.com/address@hidden
And the second discussion under Jordan's counter-proposal:
http://mid.mail-archive.com/address@hidden
http://mid.mail-archive.com/address@hidden
http://mid.mail-archive.com/address@hidden
http://mid.mail-archive.com/address@hidden
Thanks
Laszlo