OvmfPkg/AmdSev/AmdSevX64.dsc | 8 ++++++++ OvmfPkg/AmdSev/AmdSevX64.fdf | 2 ++ .../PlatformBootManagerLib/BdsPlatform.c | 17 +++++++++-------- .../DxeTcg2PhysicalPresenceLib.c | 4 ++++ OvmfPkg/OvmfPkgIa32.dsc | 8 ++++++++ OvmfPkg/OvmfPkgIa32.fdf | 2 ++ OvmfPkg/OvmfPkgIa32X64.dsc | 8 ++++++++ OvmfPkg/OvmfPkgIa32X64.fdf | 2 ++ OvmfPkg/OvmfPkgX64.dsc | 8 ++++++++ OvmfPkg/OvmfPkgX64.fdf | 2 ++ 10 files changed, 53 insertions(+), 8 deletions(-)
This series of patches adds support for disabling the TPM 2 platform hierarchy to Ovmf. To be able to do this we have to handle TPM 2 physical presence interface (PPI) opcodes before the TPM 2 platform hierarchy is disabled otherwise TPM 2 commands that are sent due to the PPI opcodes may fail if the platform hierarchy is already disabled. Therefore, we need to invoke the handler function Tcg2PhysicalPresenceLibProcessRequest from within PlatformBootManagerBeforeConsole. Since handling of PPI opcodes may require interaction with the user, we also move PlatformInitializeConsole to before the handling of PPI codes so that the keyboard is available when needed. The PPI handling code will activate the default consoles only if it requires user interaction. The question to answer at this point is whether the rearragement of functions is correct or what an alternative should look like. There are other BdsPlatform files that may need similar changes in a later revision of this series. Regards, Stefan Stefan Berger (4): OvmfPkg/TPM PPI: Connect default consoles for user interaction OvmfPkg: Handle TPM 2 physical presence codes much earlier OvmfPkg: Reference new Tcg2PlatformDxe in the build system for compilation OvmfPkg: Reference new Tcg2PlatformPei in the build system OvmfPkg/AmdSev/AmdSevX64.dsc | 8 ++++++++ OvmfPkg/AmdSev/AmdSevX64.fdf | 2 ++ .../PlatformBootManagerLib/BdsPlatform.c | 17 +++++++++-------- .../DxeTcg2PhysicalPresenceLib.c | 4 ++++ OvmfPkg/OvmfPkgIa32.dsc | 8 ++++++++ OvmfPkg/OvmfPkgIa32.fdf | 2 ++ OvmfPkg/OvmfPkgIa32X64.dsc | 8 ++++++++ OvmfPkg/OvmfPkgIa32X64.fdf | 2 ++ OvmfPkg/OvmfPkgX64.dsc | 8 ++++++++ OvmfPkg/OvmfPkgX64.fdf | 2 ++ 10 files changed, 53 insertions(+), 8 deletions(-) -- 2.31.1 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#80613): https://edk2.groups.io/g/devel/message/80613 Mute This Topic: https://groups.io/mt/85588957/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
Hi Stefan I recommend we add some comment in the code on the "trusted console" definition. [Patch 1] + // Console for user interaction // We need connect all trusted console for TCG PP. Here we treat all console in OVMF to be trusted console. + EfiBootManagerConnectAllDefaultConsoles (); [Patch 2] // We need connect all trusted console for TCG PP. Here we treat all console in OVMF to be trusted console. + PlatformInitializeConsole ( + XenDetected() ? gXenPlatformConsole : gPlatformConsole); With that change, Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com> > -----Original Message----- > From: Stefan Berger <stefanb@linux.vnet.ibm.com> > Sent: Tuesday, September 14, 2021 4:57 AM > To: devel@edk2.groups.io > Cc: mhaeuser@posteo.de; spbrogan@outlook.com; > marcandre.lureau@redhat.com; kraxel@redhat.com; Yao, Jiewen > <jiewen.yao@intel.com>; Stefan Berger <stefanb@linux.vnet.ibm.com> > Subject: [RFC PATCH v1 0/4] OvmfPkg: Disable the TPM 2 platform hierarchy > > This series of patches adds support for disabling the TPM 2 platform > hierarchy to Ovmf. To be able to do this we have to handle TPM 2 > physical presence interface (PPI) opcodes before the TPM 2 platform > hierarchy is disabled otherwise TPM 2 commands that are sent due to the > PPI opcodes may fail if the platform hierarchy is already disabled. > Therefore, we need to invoke the handler function > Tcg2PhysicalPresenceLibProcessRequest from within > PlatformBootManagerBeforeConsole. Since handling of PPI opcodes may > require > interaction with the user, we also move PlatformInitializeConsole > to before the handling of PPI codes so that the keyboard is available > when needed. The PPI handling code will activate the default consoles > only if it requires user interaction. > > The question to answer at this point is whether the rearragement of > functions is correct or what an alternative should look like. There > are other BdsPlatform files that may need similar changes in a later > revision of this series. > > Regards, > Stefan > > Stefan Berger (4): > OvmfPkg/TPM PPI: Connect default consoles for user interaction > OvmfPkg: Handle TPM 2 physical presence codes much earlier > OvmfPkg: Reference new Tcg2PlatformDxe in the build system for > compilation > OvmfPkg: Reference new Tcg2PlatformPei in the build system > > OvmfPkg/AmdSev/AmdSevX64.dsc | 8 ++++++++ > OvmfPkg/AmdSev/AmdSevX64.fdf | 2 ++ > .../PlatformBootManagerLib/BdsPlatform.c | 17 +++++++++-------- > .../DxeTcg2PhysicalPresenceLib.c | 4 ++++ > OvmfPkg/OvmfPkgIa32.dsc | 8 ++++++++ > OvmfPkg/OvmfPkgIa32.fdf | 2 ++ > OvmfPkg/OvmfPkgIa32X64.dsc | 8 ++++++++ > OvmfPkg/OvmfPkgIa32X64.fdf | 2 ++ > OvmfPkg/OvmfPkgX64.dsc | 8 ++++++++ > OvmfPkg/OvmfPkgX64.fdf | 2 ++ > 10 files changed, 53 insertions(+), 8 deletions(-) > > -- > 2.31.1 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#80632): https://edk2.groups.io/g/devel/message/80632 Mute This Topic: https://groups.io/mt/85588957/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On 9/13/21 10:18 PM, Yao, Jiewen wrote: > Hi Stefan > I recommend we add some comment in the code on the "trusted console" definition. > > [Patch 1] > + // Console for user interaction > // We need connect all trusted console for TCG PP. Here we treat all console in OVMF to be trusted console. > + EfiBootManagerConnectAllDefaultConsoles (); > > > [Patch 2] > // We need connect all trusted console for TCG PP. Here we treat all console in OVMF to be trusted console. > + PlatformInitializeConsole ( > + XenDetected() ? gXenPlatformConsole : gPlatformConsole); > > With that change, Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com> Thanks. I'll post v2 once the tests have run through. I am also cc'ing ArmVirtPkg maintainers now since we'll need to think about how to do this on ARM for the TPM 2 platform hierarchy disablement. The relevant code we just added is here: https://github.com/tianocore/edk2/tree/master/SecurityPkg/Tcg/Tcg2PlatformDxe https://github.com/tianocore/edk2/tree/master/SecurityPkg/Library/PeiDxeTpmPlatformHierarchyLib The function we need to have invoked [ConfigureTpmPlatformHierarchy ()] one way or another is here: https://github.com/tianocore/edk2/blob/master/SecurityPkg/Library/PeiDxeTpmPlatformHierarchyLib/PeiDxeTpmPlatformHierarchyLib.c#L241 On x86 this function is called via gEfiDxeSmmReadyToLockProtocolGuid which was registered/subscribed to in the entrypoint function of Tcg2PlaformDxe here: https://github.com/tianocore/edk2/blob/master/SecurityPkg/Tcg/Tcg2PlatformDxe/Tcg2PlatformDxe.c#L66 As far as I know there's no SMM mode on ARM. So what's the best way of doing this? Should we call the function ConfigureTpmPlatformHierarchy () directly from some point in ArmVirtPkg? [ https://github.com/tianocore/edk2/blob/master/SecurityPkg/Tcg/Tcg2PlatformDxe/Tcg2PlatformDxe.c#L49 ] Or should ARM also have/emulate a 'gEfiDxeSmmReadyToLockProtocolGuid' even though it doesn't have an SMM mode? Regards, Stefan > > > >> -----Original Message----- >> From: Stefan Berger <stefanb@linux.vnet.ibm.com> >> Sent: Tuesday, September 14, 2021 4:57 AM >> To: devel@edk2.groups.io >> Cc: mhaeuser@posteo.de; spbrogan@outlook.com; >> marcandre.lureau@redhat.com; kraxel@redhat.com; Yao, Jiewen >> <jiewen.yao@intel.com>; Stefan Berger <stefanb@linux.vnet.ibm.com> >> Subject: [RFC PATCH v1 0/4] OvmfPkg: Disable the TPM 2 platform hierarchy >> >> This series of patches adds support for disabling the TPM 2 platform >> hierarchy to Ovmf. To be able to do this we have to handle TPM 2 >> physical presence interface (PPI) opcodes before the TPM 2 platform >> hierarchy is disabled otherwise TPM 2 commands that are sent due to the >> PPI opcodes may fail if the platform hierarchy is already disabled. >> Therefore, we need to invoke the handler function >> Tcg2PhysicalPresenceLibProcessRequest from within >> PlatformBootManagerBeforeConsole. Since handling of PPI opcodes may >> require >> interaction with the user, we also move PlatformInitializeConsole >> to before the handling of PPI codes so that the keyboard is available >> when needed. The PPI handling code will activate the default consoles >> only if it requires user interaction. >> >> The question to answer at this point is whether the rearragement of >> functions is correct or what an alternative should look like. There >> are other BdsPlatform files that may need similar changes in a later >> revision of this series. >> >> Regards, >> Stefan >> >> Stefan Berger (4): >> OvmfPkg/TPM PPI: Connect default consoles for user interaction >> OvmfPkg: Handle TPM 2 physical presence codes much earlier >> OvmfPkg: Reference new Tcg2PlatformDxe in the build system for >> compilation >> OvmfPkg: Reference new Tcg2PlatformPei in the build system >> >> OvmfPkg/AmdSev/AmdSevX64.dsc | 8 ++++++++ >> OvmfPkg/AmdSev/AmdSevX64.fdf | 2 ++ >> .../PlatformBootManagerLib/BdsPlatform.c | 17 +++++++++-------- >> .../DxeTcg2PhysicalPresenceLib.c | 4 ++++ >> OvmfPkg/OvmfPkgIa32.dsc | 8 ++++++++ >> OvmfPkg/OvmfPkgIa32.fdf | 2 ++ >> OvmfPkg/OvmfPkgIa32X64.dsc | 8 ++++++++ >> OvmfPkg/OvmfPkgIa32X64.fdf | 2 ++ >> OvmfPkg/OvmfPkgX64.dsc | 8 ++++++++ >> OvmfPkg/OvmfPkgX64.fdf | 2 ++ >> 10 files changed, 53 insertions(+), 8 deletions(-) >> >> -- >> 2.31.1 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#80653): https://edk2.groups.io/g/devel/message/80653 Mute This Topic: https://groups.io/mt/85588957/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
© 2016 - 2024 Red Hat, Inc.