From: "Marc-André Lureau" <marcandre.lureau@gmail.com>
To: Laszlo Ersek <lersek@redhat.com>
Cc: edk2-devel@lists.01.org, Peter Jones <pjones@redhat.com>,
Jiewen Yao <jiewen.yao@intel.com>, QEMU <qemu-devel@nongnu.org>,
Javier Martinez Canillas <javierm@redhat.com>
Subject: Re: [PATCH 2/7] ovmf: link with Tcg2ConfigPei module
Date: Thu, 1 Mar 2018 15:59:41 +0100 [thread overview]
Message-ID: <CAJ+F1CKnX8+wXPzV0wOr54VKLb+A2y6iVkrtOckpmzdqujmk1Q@mail.gmail.com> (raw)
In-Reply-To: <080742f0-0f3c-bf8e-83d7-e473417cc172@redhat.com>
Hi
On Fri, Feb 23, 2018 at 6:31 PM, Laszlo Ersek <lersek@redhat.com> wrote:
> On 02/23/18 14:23, marcandre.lureau@redhat.com wrote:
>> From: Marc-André Lureau <marcandre.lureau@redhat.com>
>>
>> This module initializes TPM device type based on variable and
>> detection.
>
> (1) I suggest we say the following here:
>
> "The Tcg2ConfigPei module informs the firmware globally about the TPM
> device type, by setting the PcdTpmInstanceGuid PCD to the appropriate
> GUID value. The original module under SecurityPkg can perform device
> detection, or read a cached value from a non-volatile UEFI variable.
> OvmfPkg's clone of the module always performs the hardware detection."
>
ok
> Becase...
>
>> The module requires VariablePei, which is built with
>> MEM_VARSTORE_EMU_ENABLE=FALSE.
>
> (2) ... as I hinted in my response to your blurb, and also as suggested
> by "Tcg2ConfigPei.inf", we should clone Tcg2ConfigPei for OVMF, and
> *trim it* quite a bit.
>
> - The new location should be "OvmfPkg/Tcg/Tcg2Config/".
>
> - We need not copy the ".uni" file (also drop MODULE_UNI_FILE from the
> INF file)
>
> - Re-generate FILE_GUID in the INF file with "uuidgen"
>
> - Remove all PEI-phase variable access; always perform the hw detection.
>
> - I would even suggest removing support for TPM1.2. Just check whether
> TPM2 is available or not.
>
ok
>
> (3) Ultimately, this is what the module should do:
>
> - Check the QEMU hardware for TPM2 availability only
>
> - If found, set the dynamic PCD "PcdTpmInstanceGuid" to
> &gEfiTpmDeviceInstanceTpm20DtpmGuid. This is what informs the rest of
> the firmware about the TPM type.
>
> - Install the gEfiTpmDeviceSelectedGuid PPI. This action permits the
> PEI_CORE to dispatch the Tcg2Pei module, which consumes the above PCD.
> In effect, the gEfiTpmDeviceSelectedGuid PPI serializes the setting
> and the consumption of the "TPM type" PCD.
>
> - If no TPM2 was found, install gPeiTpmInitializationDonePpiGuid.
> (Normally this is performed by Tcg2Pei, but Tcg2Pei doesn't do it if
> no TPM2 is available. So in that case our Tcg2ConfigPei must do it.)
ok
>
> (4) Regarding the TPM detection itself. It looks like DetectTpmDevice()
> [SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigPeim.c] calls a number of TPM1.2
> functions. If the earliest one fails, it assumes "no TPM" at all, but if
> only a later call fails, it deduces, from the 1.2 failure, that TPM2 exists.
>
> I think we can do better than this, in our Tcg2ConfigPei clone:
>
> - We should call Tpm2RequestUseTpm() directly, from
> "SecurityPkg/Include/Library/Tpm2DeviceLib.h".
>
> - And, Tpm2Startup(), from
> "SecurityPkg/Include/Library/Tpm2CommandLib.h", will be called by Tcg2Pei.
ok
>
> (5) Finally, there's no need to set "PcdTpmInitializationPolicy" to
> anything. I don't see it consumed by any module that we should include
> in OVMF. (More on this below.)
>
ok
>
> (6) Now, I realize Tcg2Pei *apparently* depends on
> gEfiPeiReadOnlyVariable2PpiGuid (i.e., read-only variable access in the
> PEI phase) as well. That's a bug in the INF file (the [depex] section).
> If you grep the Tcg2Pei module source for the GUID, the [depex] section
> is the only hit. Can you please submit a separate patch that removes it
> from the depex?
I don't get how you came to that conclusion, both
SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigPeim.c and
SecurityPkg/Tcg/Tcg2Config/TpmDetection.c match. Apparently, the
variable is used in s3 mode, in DetectTpmDevice().
I'll drop it from OvmfPkg version for now.
>
>
>> CC: Laszlo Ersek <lersek@redhat.com>
>> CC: Stefan Berger <stefanb@linux.vnet.ibm.com>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
>> ---
>> OvmfPkg/OvmfPkgX64.dsc | 20 ++++++++++++++++++++
>> OvmfPkg/OvmfPkgX64.fdf | 3 +++
>> 2 files changed, 23 insertions(+)
>
> Is there any particular reason to exclude the Ia32 and Ia32X64 builds?
>
> If not, then please modify all three sets of dsc/fdf files identically.
I'd rather keep this as a TODO item for now, since we are not close to
a final version, and it's annoying to have to fix each files etc..
>
>> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
>> index 32c57b04e1..b5cbe8430f 100644
>> --- a/OvmfPkg/OvmfPkgX64.dsc
>> +++ b/OvmfPkg/OvmfPkgX64.dsc
>> @@ -40,6 +40,7 @@
>
> (7) Please implement the following git settings in your edk2 clone:
>
> https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers#contrib-05
>
> (in particular "xfuncname")
>
> and
>
> https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers#contrib-09
>
> This will help reviewers see what section of the DSC / FDF / INI / DEC
> files are modified by a patch hunk.
>
done
>> DEFINE SMM_REQUIRE = FALSE
>> DEFINE TLS_ENABLE = FALSE
>> DEFINE MEM_VARSTORE_EMU_ENABLE = TRUE
>> + DEFINE TPM2_ENABLE = FALSE
>>
>> #
>> # Flash size selection. Setting FD_SIZE_IN_KB on the command line directly to
>> @@ -209,6 +210,11 @@
>> OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
>> XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
>>
>> +!if $(TPM2_ENABLE) == TRUE
>> + Tpm12CommandLib|SecurityPkg/Library/Tpm12CommandLib/Tpm12CommandLib.inf
>> + Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
>> +!endif
>> +
>
> (8) For the patch, as posted, resolving Tpm2CommandLib looks unneeded,
> because "SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf" doesn't seem to
> depend on that lib class.
>
> However, for the OvmfPkg clone of Tcg2ConfigPei that I'm suggesting
> here, *only* the Tpm2CommandLib resolution will be necessary.
>
iirc, I tried removing it and it failed to link. Anyway, next version
will use tpm2 only.
>> [LibraryClasses.common]
>> BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
>>
>> @@ -272,6 +278,10 @@
>> QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/PeiQemuFwCfgS3LibFwCfg.inf
>> PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
>> QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgPeiLib.inf
>> +!if $(TPM2_ENABLE)
>> + Tpm12DeviceLib|SecurityPkg/Library/Tpm12DeviceLibDTpm/Tpm12DeviceLibDTpm.inf
>> + Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2DeviceLibDTpm.inf
>> +!endif
>
> (9) Again, only the Tpm2DeviceLib resolution should be necessary (for
> our clone).
>
> (10) Furthermore, is there any particular reason you add this resolution
> only for PEIMs? Are you going to add different resolutions later, for
> different module types?
>
I followed SecurityPkg dsc, they use Tpm2DeviceLibRouterDxe.inf and
Tpm2DeviceLibTcg2.inf for some reason I don't quite understand yet.
>>
>> [LibraryClasses.common.DXE_CORE]
>> HobLib|MdePkg/Library/DxeCoreHobLib/DxeCoreHobLib.inf
>> @@ -558,6 +568,12 @@
>>
>> gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x00
>>
>> +!if $(TPM2_ENABLE) == TRUE
>> + gEfiSecurityPkgTokenSpaceGuid.PcdTpmInstanceGuid|{0xb6, 0xe5, 0x01, 0x8b, 0x19, 0x4f, 0xe8, 0x46, 0xab, 0x93, 0x1c, 0x53, 0x67, 0x1b, 0x90, 0xcc}
>
> (11) This is wrong, IMO. The value you set here is
> "gEfiTpmDeviceInstanceTpm12Guid", which I can't explain.
>
> In order for the PCD to behave dynamically, we should indeed provide a
> dynamic default. But that default value should be all-bits-zero (put
> differently, "gEfiTpmDeviceInstanceNoneGuid"). The actual value (based
> on hardware detection) should be set by our Tcg2ConfigPei clone (see
> near the top).
ok
>
>> + gEfiSecurityPkgTokenSpaceGuid.PcdTpm2InitializationPolicy|1
>> + gEfiSecurityPkgTokenSpaceGuid.PcdTpmInitializationPolicy|1
>> +!endif
>
> (12) There is no need to set PcdTpmInitializationPolicy, it should not
> be used (either set or read) by any module we include in OVMF.
>
> (13) There is also no need to set PcdTpm2InitializationPolicy. While we
> *will* include Tcg2Pei, that module only consumes the PCD, so actual
> dynamic behavior is not needed. Furthermore, the top-level default in
> "SecurityPkg/SecurityPkg.dsc" is already 1, so we can simply inherit
> that. It should cause Tcg2Pei to perform a full init on the TPM2 chip.
>
ok
>> +
>> ################################################################################
>> #
>> # Components Section - list of all EDK II Modules needed by this Platform.
>> @@ -629,6 +645,10 @@
>>
>> MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
>>
>> +!if $(TPM2_ENABLE) == TRUE
>> + SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf
>> +!endif
>> +
>
> (14) Please move this addition higher up in the DSC file, so that it
> lands at the end of:
>
> #
> # PEI Phase modules
> #
>
> just above
>
> #
> # DXE Phase modules
> #
>
done
>> !if $(SECURE_BOOT_ENABLE) == TRUE
>> MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf {
>> <LibraryClasses>
>> diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
>> index bb46a409d9..dc35d0a1f7 100644
>> --- a/OvmfPkg/OvmfPkgX64.fdf
>> +++ b/OvmfPkg/OvmfPkgX64.fdf
>> @@ -168,6 +168,9 @@ INF UefiCpuPkg/CpuMpPei/CpuMpPei.inf
>> INF MdeModulePkg/Universal/FaultTolerantWritePei/FaultTolerantWritePei.inf
>> INF MdeModulePkg/Universal/Variable/Pei/VariablePei.inf
>> !endif
>> +!if $(TPM2_ENABLE) == TRUE
>> +INF SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf
>> +!endif
>>
>> ################################################################################
>>
>>
>
> (15) This seems correct, yes; with the remark that once you drop the
> dependence on PEI phase variable access, the addition should follow
>
> INF UefiCpuPkg/CpuMpPei/CpuMpPei.inf
>
done
> directly.
>
> Thanks!
> Laszlo
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
--
Marc-André Lureau
next prev parent reply other threads:[~2018-03-01 14:53 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-23 13:23 [PATCH 0/7] RFC: ovmf: preliminary TPM2 support marcandre.lureau
2018-02-23 13:23 ` [PATCH 1/7] SecurityPkg/Tcg2Pei: drop Tcg2PhysicalPresenceLib dependency marcandre.lureau
2018-02-23 15:58 ` Laszlo Ersek
2018-02-24 0:09 ` Yao, Jiewen
2018-03-02 14:34 ` Laszlo Ersek
2018-02-23 13:23 ` [PATCH 2/7] ovmf: link with Tcg2ConfigPei module marcandre.lureau
2018-02-23 17:31 ` Laszlo Ersek
2018-03-01 14:59 ` Marc-André Lureau [this message]
2018-03-02 10:50 ` Laszlo Ersek
2018-02-23 13:23 ` [PATCH 3/7] HACK: HobLib: workaround infinite loop marcandre.lureau
2018-02-23 19:14 ` Laszlo Ersek
2018-02-23 19:45 ` Andrew Fish
2018-03-05 14:05 ` Marc-André Lureau
2018-03-05 18:22 ` Laszlo Ersek
2018-03-05 20:18 ` Andrew Fish
2018-03-06 0:45 ` Brian J. Johnson
2018-03-06 8:38 ` Laszlo Ersek
2018-03-06 2:02 ` Gao, Liming
2018-02-23 13:23 ` [PATCH 4/7] ovmf: link with Tcg2Pei module marcandre.lureau
2018-02-26 9:38 ` Laszlo Ersek
2018-03-01 15:08 ` Marc-André Lureau
2018-03-02 10:51 ` Laszlo Ersek
2018-02-23 13:23 ` [PATCH 5/7] ovmf: link with Tcg2Dxe module marcandre.lureau
2018-02-26 9:50 ` Laszlo Ersek
2018-03-05 15:45 ` Marc-André Lureau
2018-03-05 19:25 ` Laszlo Ersek
2018-02-23 13:23 ` [PATCH 6/7] ovmf: link with Tcg2ConfigDxe module marcandre.lureau
2018-02-26 9:58 ` Laszlo Ersek
2018-03-01 16:59 ` Stefan Berger
2018-03-02 11:12 ` Laszlo Ersek
2018-03-02 13:35 ` [Qemu-devel] " Stefan Berger
2018-02-23 13:23 ` [PATCH 7/7] ovmf: add DxeTpm2MeasureBootLib marcandre.lureau
2018-02-26 10:29 ` Laszlo Ersek
2018-02-23 15:55 ` [PATCH 0/7] RFC: ovmf: preliminary TPM2 support Laszlo Ersek
2018-03-01 16:36 ` [Qemu-devel] " Stefan Berger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAJ+F1CKnX8+wXPzV0wOr54VKLb+A2y6iVkrtOckpmzdqujmk1Q@mail.gmail.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox