Cc probe lib.bz3974.v4 #3290
Merged
Cc probe lib.bz3974.v4 #3290
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3974 SecPeiCcProbeLib is designed to probe the Confidential Computing guest type in SEC/PEI phase. The CC guest type was set by each CC guest at the beginning of boot up and saved in PcdOvmfWorkArea. Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Min Xu <min.m.xu@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3974 CcProbeLib once was designed to probe the Confidential Computing guest type by checking the PcdOvmfWorkArea. But this memory is allocated with either EfiACPIMemoryNVS or EfiBootServicesData. It cannot be accessed after ExitBootService. Please see the detailed analysis in BZ#3974. To fix this issue, CcProbeLib is redesigned as 2 implementation: - SecPeiCcProbeLib - DxeCcProbeLib In SecPeiCcProbeLib we check the CC guest type by reading the PcdOvmfWorkArea. Because it is used in SEC / PEI and we don't worry about the issues in BZ#3974. In DxeCcProbeLib we cache the GuestType in Ovmf work area in a variable. After that the Guest type is returned with the cached value. So that we don't need to worry about the access to Ovmf work area after ExitBootService. The reason why we probe CC guest type in 2 different ways is the global varialbe. Global variable cannot be used in SEC/PEI and CcProbe is called very frequently. Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Min Xu <min.m.xu@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3974
CcProbeLib once was designed to probe the Confidential Computing guest
type by checking the PcdOvmfWorkArea. But this memory is allocated with
either EfiACPIMemoryNVS or EfiBootServicesData. It cannot be accessed
after ExitBootService. Please see the detailed analysis in BZ#3974.
To fix this issue, CcProbeLib is re-designed as 2 implementation:
In SecPeiCcProbeLib we check the CC guest type by reading the
PcdOvmfWorkArea. Because it is used in SEC / PEI and we don't worry about
the issues in BZ#3974.
In DxeCcProbeLib we cache the GuestType in Ovmf work area in a global
variable. After that the Guest type is returned with the cached value.
So that we don't need to worry about the access to Ovmf work area after
ExitBootService.
The reason why we probe CC guest type in 2 different ways is the global
variable. Global variable cannot be used in SEC/PEI and CcProbe is called
very frequently.
Code: https://github.com/mxu9/edk2/tree/CcProbeLib.BZ3974.v4
v5 changes:
v4 changes:
that we guarantee the Cc guest type is read early enough.
v3 changes:
DxeCcProbeLib. The difference between the 2 implementation is the
cache of the CcGuestType.
v2 changes:
https://edk2.groups.io/g/devel/message/92599
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Yuan Yu <yuanyu@google.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Min M Xu (2):
OvmfPkg: Add SecPeiCcProbeLib
OvmfPkg: Update CcProbeLib to DxeCcProbeLib
OvmfPkg/IntelTdx/IntelTdxX64.dsc | 3 +-
OvmfPkg/Library/CcProbeLib/DxeCcProbeLib.c | 68 +++++++++++++++++++
OvmfPkg/Library/CcProbeLib/DxeCcProbeLib.inf | 26 +++++++
.../{CcProbeLib.c => SecPeiCcProbeLib.c} | 0
.../{CcProbeLib.inf => SecPeiCcProbeLib.inf} | 8 +--
OvmfPkg/OvmfPkgX64.dsc | 5 +-
6 files changed, 104 insertions(+), 6 deletions(-)
create mode 100644 OvmfPkg/Library/CcProbeLib/DxeCcProbeLib.c
create mode 100644 OvmfPkg/Library/CcProbeLib/DxeCcProbeLib.inf
rename OvmfPkg/Library/CcProbeLib/{CcProbeLib.c => SecPeiCcProbeLib.c} (100%)
rename OvmfPkg/Library/CcProbeLib/{CcProbeLib.inf => SecPeiCcProbeLib.inf} (65%)