Re: [PATCH v8 17/32] OvmfPkg/MemEncryptSevLib: add support to validate > 4GB memory in PEI phase


Brijesh Singh
 

On 9/22/21 3:21 AM, Gerd Hoffmann wrote:
On Mon, Sep 20, 2021 at 01:45:49PM -0500, Brijesh Singh wrote:
BZ: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D3275&;data=04%7C01%7Cbrijesh.singh%40amd.com%7Cdb7ae27f87684e0252d008d97da1f85f%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637678956888503398%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Cm1E%2BJSrQ%2B%2BCjv5ZqC%2BXNqVGbzwZ32PFGDTZtoL8e84%3D&reserved=0

The initial page built during the SEC phase is used by the
MemEncryptSevSnpValidateSystemRam() for the system RAM validation. The
page validation process requires using the PVALIDATE instruction; the
instruction accepts a virtual address of the memory region that needs
to be validated. If hardware encounters a page table walk failure (due
to page-not-present) then it raises #GP.

The initial page table built in SEC phase address up to 4GB. Add an
internal function to extend the page table to cover > 4GB. The function
builds 1GB entries in the page table for access > 4GB. This will provide
the support to call PVALIDATE instruction for the virtual address >
4GB in PEI phase.
Hmm, well, playing with page tables like that in sev-specific code
instead of having memory core handle this properly is quite hackish.

What is the long-term plan with this? I assume once support for lazy
acceptance/validation is merged we can simply delete this?
Yes, this is just an interim problem. Once we move to lazy validation
then this will be removed.



Assuming this is only a temporary solution I think we can tolerate the
hacks.

take care,
Gerd

Join devel@edk2.groups.io to automatically receive all group messages.