summaryrefslogtreecommitdiffstats
path: root/OvmfPkg/ResetVector
Commit message (Collapse)AuthorAgeFilesLines
* OvmfPkg/ResetVector: Clear SEV encryption bit for non-leaf PTEsMichael Roth2024-05-022-11/+14
| | | | | | | | | | | | | | | | | | Future changes will make use of CpuPageTableLib to handle splitting page table mappings during SEC phase. While it's not strictly required by hardware, CpuPageTableLib relies on non-leaf PTEs never having the encryption bit set, so go ahead change the page table setup code to satisfy this expectation. Suggested-by: Tom Lendacky <thomas.lendacky@amd.com> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Michael Roth <michael.roth@amd.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg: Create a calling area used to communicate with the SVSMTom Lendacky2024-04-173-3/+16
| | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654 An SVSM requires a calling area page whose address (CAA) is used by the SVSM to communicate and process the SVSM request. Add a pre-defined page area to the OvmfPkg and AmdSev packages and define corresponding PCDs used to communicate the location and size of the area. Keep the AmdSev package in sync with the OvmfPkg and adjust the AmdSev launch and hash area memory locations. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Michael Roth <michael.roth@amd.com> Cc: Min Xu <min.m.xu@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
* OvmfPkg/ResetVector: wire up 5-level paging for TDXGerd Hoffmann2024-03-012-1/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | BSP workflow is quite simliar to the non-coco case. TDX_WORK_AREA_PGTBL_READY is used to record the paging mode: 1 == 4-level paging 2 == 5-level paging APs will look at TDX_WORK_AREA_PGTBL_READY to figure whenever they should enable 5-level paging or not. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-Id: <20240301074402.98625-9-kraxel@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: move "CheckForSev:" label into "%if PG_5_LEVEL" scope, as discussed with Gerd] Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Oliver Steffen <osteffen@redhat.com> Cc: Michael Roth <michael.roth@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Tom Lendacky <thomas.lendacky@amd.com> [lersek@redhat.com: turn the "Cc:" message headers from Gerd's on-list posting into "Cc:" tags in the commit message, in order to pacify "PatchCheck.py"]
* OvmfPkg/ResetVector: print post codes for 4/5 level pagingGerd Hoffmann2024-03-011-0/+8
| | | | | | | | | | | | | | | | Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20240301074402.98625-8-kraxel@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Oliver Steffen <osteffen@redhat.com> Cc: Michael Roth <michael.roth@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Tom Lendacky <thomas.lendacky@amd.com> [lersek@redhat.com: turn the "Cc:" message headers from Gerd's on-list posting into "Cc:" tags in the commit message, in order to pacify "PatchCheck.py"]
* OvmfPkg/ResetVector: add 5-level paging supportGerd Hoffmann2024-03-013-0/+102
| | | | | | | | | | | | | | | | | | | Add macros to check for 5-level paging and gigabyte page support. Enable 5-level paging for the non-confidential-computing case. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-Id: <20240301074402.98625-7-kraxel@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Oliver Steffen <osteffen@redhat.com> Cc: Michael Roth <michael.roth@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Tom Lendacky <thomas.lendacky@amd.com> [lersek@redhat.com: turn the "Cc:" message headers from Gerd's on-list posting into "Cc:" tags in the commit message, in order to pacify "PatchCheck.py"]
* OvmfPkg/ResetVector: split SEV and non-CoCo workflowsGerd Hoffmann2024-03-012-16/+15
| | | | | | | | | | | | | | | | | | | | | | | | Use separate control flows for SEV and non-CoCo cases. SevClearPageEncMaskForGhcbPage and GetSevCBitMaskAbove31 will now only be called when running in SEV mode, so the SEV check in these functions is not needed any more. No functional change. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20240301074402.98625-6-kraxel@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Oliver Steffen <osteffen@redhat.com> Cc: Michael Roth <michael.roth@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Tom Lendacky <thomas.lendacky@amd.com> [lersek@redhat.com: turn the "Cc:" message headers from Gerd's on-list posting into "Cc:" tags in the commit message, in order to pacify "PatchCheck.py"]
* OvmfPkg/ResetVector: split TDX BSP workflowGerd Hoffmann2024-03-012-9/+10
| | | | | | | | | | | | | | | | | | | | | | | Create a separate control flow for TDX BSP. TdxPostBuildPageTables will now only be called when running in TDX mode, so the TDX check in that function is not needed any more. No functional change. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20240301074402.98625-5-kraxel@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Oliver Steffen <osteffen@redhat.com> Cc: Michael Roth <michael.roth@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Tom Lendacky <thomas.lendacky@amd.com> [lersek@redhat.com: turn the "Cc:" message headers from Gerd's on-list posting into "Cc:" tags in the commit message, in order to pacify "PatchCheck.py"]
* OvmfPkg/ResetVector: add CreatePageTables4Level macroGerd Hoffmann2024-03-011-31/+39
| | | | | | | | | | | | | | | | | | | Move code to create 4-level page tables to a nasm macro. No functional change. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20240301074402.98625-4-kraxel@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Oliver Steffen <osteffen@redhat.com> Cc: Michael Roth <michael.roth@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Tom Lendacky <thomas.lendacky@amd.com> [lersek@redhat.com: turn the "Cc:" message headers from Gerd's on-list posting into "Cc:" tags in the commit message, in order to pacify "PatchCheck.py"]
* OvmfPkg/ResetVector: add ClearOvmfPageTables macroGerd Hoffmann2024-03-011-16/+19
| | | | | | | | | | | | | | | | | | | Move code to clear the page tables to a nasm macro. No functional change. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20240301074402.98625-3-kraxel@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Oliver Steffen <osteffen@redhat.com> Cc: Michael Roth <michael.roth@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Tom Lendacky <thomas.lendacky@amd.com> [lersek@redhat.com: turn the "Cc:" message headers from Gerd's on-list posting into "Cc:" tags in the commit message, in order to pacify "PatchCheck.py"]
* OvmfPkg/ResetVector: improve page table flag namesGerd Hoffmann2024-03-011-17/+22
| | | | | | | | | | | | | | | | | | | | Add comments, rename some of the PAGE_* flags and combined attributes. Specifically use "LARGEPAGE" instead of "2M" because that bit is used for both 2M and 1G large pages. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20240301074402.98625-2-kraxel@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Oliver Steffen <osteffen@redhat.com> Cc: Michael Roth <michael.roth@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Tom Lendacky <thomas.lendacky@amd.com> [lersek@redhat.com: turn the "Cc:" message headers from Gerd's on-list posting into "Cc:" tags in the commit message, in order to pacify "PatchCheck.py"]
* OvmfPkg/ResetVector: Fix SNP CPUID table processing results for ECX/EDXTom Lendacky2024-02-031-2/+2
| | | | | | | | | | | | | | The current support within the boot SNP CPUID table processing mistakenly swaps the ECX and EDX results. It does not have an effect at this time because current CPUID results checking does not check ECX or EDX. However, any future CPUID checks that need to check ECX or EDX may have erroneous behavior. Fix the assembler code to save ECX and EDX to the proper locations. Fixes: 34819f2caccb ("OvmfPkg/ResetVector: use SEV-SNP-validated CPUID values") Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Reviewed-by: Michael Roth <michael.roth@amd.com>
* OvmfPkg/ResetVector: send post codes to qemu debug consoleGerd Hoffmann2024-01-292-0/+40
| | | | | | | | | | | | Neat when doing ResetVector coding. Incompatible with TDX and SEV, therefore not enabled by default. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Tom Lendacky <thomas.lendacky@amd.com> Acked-by: Erdem Aktas <erdemaktas@google.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20240129122929.349726-1-kraxel@redhat.com> [lersek@redhat.com: replace "SEV" with "SEV-ES/SEV-SNP" in comment]
* OvmfPkg/ResetVector: Define SNP metadata for kernel hashesDov Murik2023-11-282-1/+21
| | | | | | | | | | | | | | | | | | | In order to allow the VMM (such as QEMU) to add a page with hashes of kernel/initrd/cmdline for measured direct boot on SNP, add it explicitly to the SNP metadata list report to the VMM. In such case, VMM should fill the page with the hashes content, or explicitly update it as a zero page (if kernel hashes are not used). Note that for SNP, the launch secret part of the page (lower 3KB) are not relevant and will remain zero. The last 1KB is used for the hashes. This should have no effect on OvmfPkgX64 targets (which don't define PcdSevLaunchSecretBase). Signed-off-by: Dov Murik <dovmurik@linux.ibm.com> Acked-by: Tom Lendacky <thomas.lendacky@amd.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg: Remove applicationProcessorEntryPointZhiguang Liu2023-09-181-12/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4494 Current reset vector uses 0xffffffe0 as AP waking vector, and expects GenFv generates code aligned on a 4k boundary which will jump to this location. However, some issues are listed below 1. GenFV doesn't generate code as the comment expects, because GenFv assumes no modifications are required to the VTF-0 'Volume Top File'. 2. Even if removing VFT0 signature and let GenFv to modify, Genfv is hard-code using another flash address 0xffffffd0. 3. In the same patch series, AP waking vector code is removed from GenFv, because no such usage anymore. The existing of first two issues also approve the usage is not available for a long time. Therefore, remove AP waking vector related code. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien@xen.org> Reviewed-by: Ray Ni <ray.ni@intel.com> Acked-by: Anthony PERARD <anthony.perard@citrix.com> Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
* OvmfPkg/ResetVector: Fix assembler bit test flag checkTom Lendacky2023-07-141-1/+1
| | | | | | | | | | | | | Commit 63c50d3ff2854a76432b752af4f2a76f33ff1974 changed the check that is used to determine if SEV-ES is active. Originally, a CMP instruction with a supporting JZ instruction was used for the check. It was changed to use the BT instruction but not JZ instruction. The result of a BT instruction changes the the carry flag (CF) and not the zero flag (ZF). As a result, the wrong condition is being checked. Update the JZ to a JNC to properly detect if SEV-ES is active. Fixes: 63c50d3ff285 ("OvmfPkg/ResetVector: cache the SEV status MSR...") Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
* OvmfPkg/ResetVector: Removing SEV-ES CPUID bit checkPeter Gonda2022-06-011-8/+0
| | | | | | | | | | | | | | The SEV-ES bit of Fn800-001F[EAX] - Bit 3 is used for a host to determine support for running SEV-ES guests. It should not be checked by a guest to determine if it is running under SEV-ES. The guest should use the SEV_STATUS MSR Bit 1 to determine if SEV-ES is enabled. This check was not part of the original SEV-ES support and was added in a91b700e38. Removing the check makes this code consistent with the Linux kernel Fixes: a91b700e38 ("Ovmf/ResetVector: Simplify and consolidate the SEV features checks") Signed-off-by: Peter Gonda <pgonda@google.com> Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
* OvmfPkg: Make an Ia32/X64 hybrid build work with SEVTom Lendacky2022-05-203-37/+47
| | | | | | | | | | | | | | | | | | | | | | | | The BaseMemEncryptSevLib functionality was updated to rely on the use of the OVMF/SEV workarea to check for SEV guests. However, this area is only updated when running the X64 OVMF build, not the hybrid Ia32/X64 build. Base SEV support is allowed under the Ia32/X64 build, but it now fails to boot as a result of the change. Update the ResetVector code to check for SEV features when built for 32-bit mode, not just 64-bit mode (requiring updates to both the Ia32 and Ia32X64 fdf files). Fixes: f1d1c337e7c0575da7fd248b2dd9cffc755940df Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Michael Roth <michael.roth@amd.com> Cc: Min Xu <min.m.xu@intel.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg/ResetVector: cache the SEV status MSR value in workareaBrijesh Singh2022-02-283-16/+28
| | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3582 In order to probe the SEV feature the BaseMemEncryptLib and Reset vector reads the SEV_STATUS MSR. Cache the value on the first read in the workarea. In the next patches the value saved in the workarea will be used by the BaseMemEncryptLib. This not only eliminates the extra MSR reads it also helps cleaning up the code in BaseMemEncryptLib. Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Acked-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg/ResetVector: use SEV-SNP-validated CPUID valuesMichael Roth2021-12-091-5/+75
| | | | | | | | | | | | | | | | | | | | | | | | CPUID instructions are issued during early boot to do things like probe for SEV support. Currently these are handled by a minimal #VC handler that uses the MSR-based GHCB protocol to fetch the CPUID values from the hypervisor. When SEV-SNP is enabled, use the firmware-validated CPUID values from the CPUID page instead [1]. [1]: SEV SNP Firmware ABI Specification, Rev. 0.8, 8.13.2.6 Cc: Michael Roth <michael.roth@amd.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Michael Roth <michael.roth@amd.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg/ResetVector: pre-validate the data pages used in SEC phaseBrijesh Singh via groups.io2021-12-093-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 An SEV-SNP guest requires that private memory (aka pages mapped encrypted) must be validated before being accessed. The validation process consist of the following sequence: 1) Set the memory encryption attribute in the page table (aka C-bit). Note: If the processor is in non-PAE mode, then all the memory accesses are considered private. 2) Add the memory range as private in the RMP table. This can be performed using the Page State Change VMGEXIT defined in the GHCB specification. 3) Use the PVALIDATE instruction to set the Validated Bit in the RMP table. During the guest creation time, the VMM encrypts the OVMF_CODE.fd using the SEV-SNP firmware provided LAUNCH_UPDATE_DATA command. In addition to encrypting the content, the command also validates the memory region. This allows us to execute the code without going through the validation sequence. During execution, the reset vector need to access some data pages (such as page tables, SevESWorkarea, Sec stack). The data pages are accessed as private memory. The data pages are not part of the OVMF_CODE.fd, so they were not validated during the guest creation. There are two approaches we can take to validate the data pages before the access: a) Enhance the OVMF reset vector code to validate the pages as described above (go through step 2 - 3). OR b) Validate the pages during the guest creation time. The SEV firmware provides a command which can be used by the VMM to validate the pages without affecting the measurement of the launch. Approach #b seems much simpler; it does not require any changes to the OVMF reset vector code. Update the OVMF metadata with the list of regions that must be pre-validated by the VMM before the boot. Cc: Michael Roth <michael.roth@amd.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg: reserve CPUID pageBrijesh Singh via groups.io2021-12-093-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 Platform features and capabilities are traditionally discovered via the CPUID instruction. Hypervisors typically trap and emulate the CPUID instruction for a variety of reasons. There are some cases where incorrect CPUID information can potentially lead to a security issue. The SEV-SNP firmware provides a feature to filter the CPUID results through the PSP. The filtered CPUID values are saved on a special page for the guest to consume. Reserve a page in MEMFD that will contain the results of filtered CPUID values. Cc: Michael Roth <michael.roth@amd.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg: reserve SNP secrets pageBrijesh Singh via groups.io2021-12-093-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 During the SNP guest launch sequence, a special secrets page needs to be inserted by the VMM. The PSP will populate the page; it will contain the VM Platform Communication Key (VMPCKs) used by the guest to send and receive secure messages to the PSP. The purpose of the secrets page in the SEV-SNP is different from the one used in SEV guests. In SEV, the secrets page contains the guest owner's private data after the remote attestation. Cc: Michael Roth <michael.roth@amd.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg/ResetVector: introduce SEV metadata descriptor for VMM useBrijesh Singh via groups.io2021-12-093-0/+49
| | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 The OvmfPkgX86 build reserves memory regions in MEMFD. The memory regions get accessed in the SEC phase. AMD SEV-SNP require that the guest's private memory be accepted or validated before access. Introduce a Guided metadata structure that describes the reserved memory regions. The VMM can locate the metadata structure by iterating through the reset vector guid and process the areas based on the platform specific requirements. Cc: Michael Roth <michael.roth@amd.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg/ResetVector: move clearing GHCB in SecMainBrijesh Singh via groups.io2021-12-091-6/+0
| | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 In preparation for SEV-SNP support move clearing of the GHCB memory from the ResetVector/AmdSev.asm to SecMain/AmdSev.c. The GHCB page is not accessed until SevEsProtocolCheck() switch to full GHCB. So, the move does not make any changes in the code flow or logic. The move will simplify the SEV-SNP support. Cc: Michael Roth <michael.roth@amd.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg: Enable TDX in ResetVectorMin Xu2021-10-246-0/+286
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | RFC： https://bugzilla.tianocore.org/show_bug.cgi?id=3429 Intel's Trust Domain Extensions (Intel TDX) refers to an Intel technology that extends Virtual Machines Extensions (VMX) and Multi-Key Total Memory Encryption (MKTME) with a new kind of virutal machines guest called a Trust Domain (TD). A TD is desinged to run in a CPU mode that protects the confidentiality of TD memory contents and the TD's CPU state from other software, including the hosting Virtual-Machine Monitor (VMM), unless explicitly shared by the TD itself. Note: Intel TDX is only available on X64, so the Tdx related changes are in X64 path. In IA32 path, there may be null stub to make the build success. This patch includes below major changes. 1. Ia32/IntelTdx.asm IntelTdx.asm includes below routines used in ResetVector - IsTdx Check if the running system is Tdx guest. - InitTdxWorkarea It initialize the TDX_WORK_AREA. Because it is called by both BSP and APs and to avoid the race condition, only BSP can initialize the WORK_AREA. AP will wait until the field of TDX_WORK_AREA_PGTBL_READY is set. - ReloadFlat32 After reset all CPUs in TDX are initialized to 32-bit protected mode. But GDT register is not set. So this routine loads the GDT then jump to Flat 32 protected mode again. - InitTdx This routine wrap above 3 routines together to do Tdx initialization in ResetVector phase. - IsTdxEnabled It is a OneTimeCall to probe if TDX is enabled by checking the CC_WORK_AREA. - CheckTdxFeaturesBeforeBuildPagetables This routine is called to check if it is Non-TDX guest, TDX-Bsp or TDX-APs. Because in TDX guest all the initialization is done by BSP (including the page tables). APs should not build the tables. - TdxPostBuildPageTables It is called after Page Tables are built by BSP. byte[TDX_WORK_AREA_PGTBL_READY] is set by BSP to indicate APs can leave spin and go. 2. Ia32/PageTables64.asm As described above only the TDX BSP build the page tables. So PageTables64.asm is updated to make sure only TDX BSP build the PageTables. TDX APs will skip the page table building and set Cr3 directly. 3. Ia16/ResetVectorVtf0.asm In Tdx all CPUs "reset" to run on 32-bit protected mode with flat descriptor (paging disabled). But in Non-Td guest the initial state of CPUs is 16-bit real mode. To resolve this conflict, BITS 16/32 is used in the ResetVectorVtf0.asm. It checks the 32-bit protected mode or 16-bit real mode, then jump to the corresponding entry point. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Brijesh Singh <brijesh.singh@amd.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> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg: Add IntelTdxMetadata.asmMin Xu2021-10-244-0/+170
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | RFC： https://bugzilla.tianocore.org/show_bug.cgi?id=3429 In TDX when host VMM creates a new guest TD, some initial set of TD-private pages are added using the TDH.MEM.PAGE.ADD function. These pages typically contain Virtual BIOS code and data along with some clear pages for stacks and heap. In the meanwhile, some configuration data need be measured by host VMM. Tdx Metadata is designed for this purpose to indicate host VMM how to do the above tasks. More detailed information of Metadata is in [TDVF] Section 11. Tdx Metadata describes the information about the image for VMM use. For example, the base address and length of the TdHob, Bfv, Cfv, etc. The offset of the Metadata is stored in a GUID-ed structure which is appended in the GUID-ed chain from a fixed GPA (0xffffffd0). In this commit there are 2 new definitions of BFV & CFV. Tdx Virtual Firmware (TDVF) includes one Firmware Volume (FV) known as the Boot Firmware Volume (BFV). The FV format is defined in the UEFI Platform Initialization (PI) spec. BFV includes all TDVF components required during boot. TDVF also include a configuration firmware volume (CFV) that is separated from the BFV. The reason is because the CFV is measured in RTMR, while the BFV is measured in MRTD. In practice BFV is the code part of Ovmf image (OVMF_CODE.fd). CFV is the vars part of Ovmf image (OVMF_VARS.fd). Since AMD SEV has already defined some SEV specific memory region in MEMFD. TDX re-uses some of the memory regions defined by SEV. - MailBox : PcdOvmfSecGhcbBackupBase|PcdOvmfSecGhcbBackupSize - TdHob : PcdOvmfSecGhcbBase|PcdOvmfSecGhcbSize [TDVF] https://software.intel.com/content/dam/develop/external/us/en/ documents/tdx-virtual-firmware-design-guide-rev-1.pdf Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Brijesh Singh <brijesh.singh@amd.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> 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>
* OvmfPkg: Clear WORK_AREA_GUEST_TYPE in Main.asmMin Xu2021-10-242-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | RFC： https://bugzilla.tianocore.org/show_bug.cgi?id=3429 Previously WORK_AREA_GUEST_TYPE was cleared in SetCr3ForPageTables64. This is workable for Legacy guest and SEV guest. But it doesn't work after Intel TDX is introduced. It is because all TDX CPUs (BSP and APs) start to run from 0xfffffff0, thus WORK_AREA_GUEST_TYPE will be cleared multi-times if it is TDX guest. So the clearance of WORK_AREA_GUEST_TYPE is moved to Main16 entry point in Main.asm. Note: WORK_AREA_GUEST_TYPE is only defined for ARCH_X64. For Intel TDX, its corresponding entry point is Main32 (which will be introduced in next commit in this patch-set). WORK_AREA_GUEST_TYPE will be cleared there. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Brijesh Singh <brijesh.singh@amd.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> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg: Copy Main.asm from UefiCpuPkg to OvmfPkg's ResetVectorMin Xu2021-10-241-0/+103
| | | | | | | | | | | | | | | | | | | | | | | | | | | | RFC： https://bugzilla.tianocore.org/show_bug.cgi?id=3429 Previously OvmfPkg/ResetVector uses the Main.asm in UefiCpuPkg/ReseteVector/Vtf0. In this Main.asm there is only Main16 entry point. This patch-set is to introduce Intel TDX into Ovmf. Main32 entry point is needed in Main.asm by Intel TDX. To reduce the complexity of Main.asm in UefiCpuPkg, OvmfPkg create its own Main.asm to meet the requirement of Intel TDX. This Main.asm is an unmodified copy (so no functional change) and the actual changes for tdx come as incremental patches. UefiCpuPkg/ResetVector/Vtf0/main.asm -> OvmfPkg/ResetVector/Main.asm Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Brijesh Singh <brijesh.singh@amd.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> 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>
* Ovmfpkg: update Ia32 build to use new work areaBrijesh Singh2021-10-191-1/+2
| | | | | | | | | | | | | | | | | | | | | | The commit 80e67af9afca added support for the generic work area concept used mainly by the encrypted VMs. In the past, the work area was preliminary used by the SEV-ES VMs. The SEV-ES support is available for the X64 builds only. But now, that work area header contains fields that nonencrypted VMs and SEV VMs can use. They can be built for IA32. So, moving the work area defines outside of X64. Fixes: 80e67af9afca ("OvmfPkg: introduce a common work area") Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg/ResetVector: move the GHCB page setup in AmdSev.asmBrijesh Singh2021-08-272-72/+92
| | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3429 While build the initial page table, the SetCr3ForPageTables64 checks whether SEV-ES is enabled. If so, clear the page encryption mask from the GHCB page. Move the logic to clear the page encryption mask in the AmdSev.asm. Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Min Xu <min.m.xu@intel.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
* OvmfPkg/ResetVector: update SEV support to use new work area formatBrijesh Singh2021-08-274-0/+14
| | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3429 Update the SEV support to switch to using the newer work area format. Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Min Xu <min.m.xu@intel.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
* OvmfPkg/AmdSev: reserve MEMFD space for for firmware config hashesJames Bottomley2021-07-293-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Split the existing 4KB page reserved for SEV launch secrets into two parts: first 3KB for SEV launch secrets and last 1KB for firmware config hashes. The area of the firmware config hashes will be attested (measured) by the PSP and thus the untrusted VMM can't pass in different files from what the guest owner allows. Declare this in the Reset Vector table using GUID 7255371f-3a3b-4b04-927b-1da6efa8d454 and a uint32_t table of a base and size value (similar to the structure used to declare the launch secret block). Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ashish Kalra <ashish.kalra@amd.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3457 Co-developed-by: Dov Murik <dovmurik@linux.ibm.com> Signed-off-by: Dov Murik <dovmurik@linux.ibm.com> Signed-off-by: James Bottomley <jejb@linux.ibm.com> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg/ResetVector: add the macro to request guest terminationBrijesh Singh via groups.io2021-07-291-42/+45
| | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 The upcoming SEV-SNP support will need to make a few additional guest termination requests depending on the failure type. Let's move the logic to request the guest termination into a macro to keep the code readable. Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Erdem Aktas <erdemaktas@google.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Acked-by: Ard Biesheuvel <ardb+tianocore@kernel.org> Suggested-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg/ResetVector: add the macro to invoke MSR protocol based VMGEXITBrijesh Singh2021-07-291-24/+47
| | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 The upcoming SEV-SNP support will need to make a few additional MSR protocol based VMGEXIT's. Add a macro that wraps the common setup and response validation logic in one place to keep the code readable. While at it, define SEV_STATUS_MSR that will be used to get the SEV STATUS MSR instead of open coding it. Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Erdem Aktas <erdemaktas@google.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Acked-by: Ard Biesheuvel <ardb+tianocore@kernel.org> Suggested-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg/ResetVector: move SEV specific code in a separate fileBrijesh Singh2021-07-293-391/+401
| | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 The PageTables64.asm was created to provide routines to set the CR3 register for 64-bit paging. During the SEV support, it grew to include a lot of the SEV stuff. Before adding more SEV features, let's move all the SEV-specific routines into a separate file. No functionality change intended. Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Erdem Aktas <erdemaktas@google.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Acked-by: Ard Biesheuvel <ardb+tianocore@kernel.org> Suggested-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg/ResetVector: Save the encryption mask at boot timeTom Lendacky2021-01-072-1/+10
| | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108 The early assembler code performs validation for some of the SEV-related information, specifically the encryption bit position. To avoid having to re-validate the encryption bit position as the system proceeds through its boot phases, save the validated encryption bit position in the SEV-ES work area for use by later phases. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <2609724859cf21f0c6d45bc323e94465dca4e621.1610045305.git.thomas.lendacky@amd.com>
* OvmfPkg/ResetVector: Perform a simple SEV-ES sanity checkTom Lendacky2021-01-071-0/+16
| | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108 If a hypervisor incorrectly reports through CPUID that SEV-ES is not active, ensure that a #VC exception was not taken. If it is found that a #VC was taken, then the code enters a HLT loop. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <afa2030b95b852313b13982df82d472187e59b92.1610045305.git.thomas.lendacky@amd.com>
* OvmfPkg/ResetVector: Validate the encryption bit position for SEV/SEV-ESTom Lendacky2021-01-073-3/+132
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108 To help mitigate against ROP attacks, add some checks to validate the encryption bit position that is reported by the hypervisor. The first check is to ensure that the hypervisor reports a bit position above bit 31. After extracting the encryption bit position from the CPUID information, the code checks that the value is above 31. If the value is not above 31, then the bit position is not valid, so the code enters a HLT loop. The second check is specific to SEV-ES guests and is a two step process. The first step will obtain random data using RDRAND and store that data to memory before paging is enabled. When paging is not enabled, all writes to memory are encrypted. The random data is maintained in registers, which are protected. The second step is that, after enabling paging, the random data in memory is compared to the register contents. If they don't match, then the reported bit position is not valid, so the code enters a HLT loop. The third check is after switching to 64-bit long mode. Use the fact that instruction fetches are automatically decrypted, while a memory fetch is decrypted only if the encryption bit is set in the page table. By comparing the bytes of an instruction fetch against a memory read of that same instruction, the encryption bit position can be validated. If the compare is not equal, then SEV/SEV-ES is active but the reported bit position is not valid, so the code enters a HLT loop. To keep the changes local to the OvmfPkg, an OvmfPkg version of the Flat32ToFlat64.asm file has been created based on the UefiCpuPkg file UefiCpuPkg/ResetVector/Vtf0/Ia32/Flat32ToFlat64.asm. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <cb9c5ab23ab02096cd964ed64115046cc706ce67.1610045305.git.thomas.lendacky@amd.com>
* Ovmf/ResetVector: Simplify and consolidate the SEV features checksTom Lendacky2021-01-071-30/+45
| | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108 Simplify and consolidate the SEV and SEV-ES checks into a single routine. This new routine will use CPUID to check for the appropriate CPUID leaves and the required values, as well as read the non-interceptable SEV status MSR (0xc0010131) to check SEV and SEV-ES enablement. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <43a660624c32b5f6c2610bf42ee39101c21aff68.1610045305.git.thomas.lendacky@amd.com>
* OvmfPkg: create a SEV secret area in the AmdSev memfdJames Bottomley2020-12-143-0/+25
| | | | | | | | | | | | | | SEV needs an area to place an injected secret where OVMF can find it and pass it up as a ConfigurationTable. This patch implements the area itself as an addition to the SEV enhanced reset vector table using an additional guid (4c2eb361-7d9b-4cc3-8081-127c90d3d294). Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3077 Signed-off-by: James Bottomley <jejb@linux.ibm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20201130202819.3910-5-jejb@linux.ibm.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com> [lersek@redhat.com: fix typo in "ResetVectorVtf0.asm" comments]
* OvmfPkg/ResetVector: convert SEV-ES Reset Block structure to be GUIDedJames Bottomley2020-12-141-11/+40
| | | | | | | | | | | | Convert the current ES reset block structure to an extensible guid based structure by appending a header and length, which allow for multiple guid based data packets to be inserted. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3077 Signed-off-by: James Bottomley <jejb@linux.ibm.com> Message-Id: <20201130202819.3910-2-jejb@linux.ibm.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Use the SEV-ES work area for the SEV-ES AP reset vectorTom Lendacky2020-08-172-0/+101
| | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 A hypervisor is not allowed to update an SEV-ES guest's register state, so when booting an SEV-ES guest AP, the hypervisor is not allowed to set the RIP to the guest requested value. Instead an SEV-ES AP must be re-directed from within the guest to the actual requested staring location as specified in the INIT-SIPI-SIPI sequence. Use the SEV-ES work area for the reset vector code that contains support to jump to the desired RIP location after having been started. This is required for only the very first AP reset. This new OVMF source file, ResetVectorVtf0.asm, is used in place of the original file through the use of the include path order set in OvmfPkg/ResetVector/ResetVector.inf under "[BuildOptions]". Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/ResetVector: Add support for a 32-bit SEV checkTom Lendacky2020-08-173-3/+277
| | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 During BSP startup, the reset vector code will issue a CPUID instruction while in 32-bit mode. When running as an SEV-ES guest, this will trigger a #VC exception. Add exception handling support to the early reset vector code to catch these exceptions. Also, since the guest is in 32-bit mode at this point, writes to the GHCB will be encrypted and thus not able to be read by the hypervisor, so use the GHCB CPUID request/response protocol to obtain the requested CPUID function values and provide these to the guest. The exception handling support is active during the SEV check and uses the OVMF temporary RAM space for a stack. After the SEV check is complete, the exception handling support is removed and the stack pointer cleared. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Create a GHCB page for use during Sec phaseTom Lendacky2020-08-173-0/+98
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 A GHCB page is needed during the Sec phase, so this new page must be created. Since the #VC exception handler routines assume that a per-CPU variable area is immediately after the GHCB, this per-CPU variable area must also be created. Since the GHCB must be marked as an un-encrypted, or shared, page, an additional pagetable page is required to break down the 2MB region where the GHCB page lives into 4K pagetable entries. Create a new entry in the OVMF memory layout for the new page table page and for the SEC GHCB and per-CPU variable pages. After breaking down the 2MB page, update the GHCB page table entry to remove the encryption mask. The GHCB page will be used by the SEC #VC exception handler. The #VC exception handler will fill in the necessary fields of the GHCB and exit to the hypervisor using the VMGEXIT instruction. The hypervisor then accesses the GHCB in order to perform the requested function. Four new fixed PCDs are needed to support the SEC GHCB page: - PcdOvmfSecGhcbBase UINT32 value that is the base address of the GHCB used during the SEC phase. - PcdOvmfSecGhcbSize UINT32 value that is the size, in bytes, of the GHCB area used during the SEC phase. - PcdOvmfSecGhcbPageTableBase UINT32 value that is address of a page table page used to break down the 2MB page into 512 4K pages. - PcdOvmfSecGhcbPageTableSize UINT32 value that is the size, in bytes, of the page table page. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Replace BSD License with BSD+Patent LicenseMichael D Kinney2019-04-093-20/+3
| | | | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=1373 Replace BSD 2-Clause License with BSD+Patent License. This change is based on the following emails: https://lists.01.org/pipermail/edk2-devel/2019-February/036260.html https://lists.01.org/pipermail/edk2-devel/2018-October/030385.html RFCs with detailed process for the license change: V3: https://lists.01.org/pipermail/edk2-devel/2019-March/038116.html V2: https://lists.01.org/pipermail/edk2-devel/2019-March/037669.html V1: https://lists.01.org/pipermail/edk2-devel/2019-March/037500.html Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/ResetVector: Set C-bit when building initial page tableBrijesh Singh2017-07-101-1/+61
| | | | | | | | | | | | | | | | | | | | | SEV guest VMs have the concept of private and shared memory. Private memory is encrypted with the guest-specific key, while shared memory may be encrypted with hypervisor key. Certain types of memory (namely instruction pages and guest page tables) are always treated as private memory by the hardware. The C-bit in PTE indicate whether the page is private or shared. The C-bit position for the PTE can be obtained from CPUID Fn8000_001F[EBX]. When SEV is active, the BIOS is encrypted by the Qemu launch sequence, we must set the C-bit when building the page table. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Tom Lendacky <Thomas.Lendacky@amd.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg/ResetVector: Depend on PCD values of the page tables.Marvin Häuser2016-11-043-11/+24
| | | | | | | | | | | | | | Currently, the value of the page tables' address is hard-coded in the ResetVector. This patch replaces these values with a PCD dependency. A check for the size has been added to alert the developer to rewrite the ASM according to the new size, if it has been changed. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Marvin Haeuser <Marvin.Haeuser@outlook.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg/ResetVector: Remove the unused ASM ResetVector.Marvin Häuser2016-11-031-53/+0
| | | | | | | | | | Remove the ResetVector.asm file as it is no longer referenced since the switch to ResetVector.nasmb. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Marvin Haeuser <Marvin.Haeuser@outlook.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/ResetVector: Remove pre-built binariesJordan Justen2014-08-184-113/+0
| | | | | | | | Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15825 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: Support building OVMF's ResetVector during the EDK II buildJordan Justen2014-08-182-0/+103
| | | | | | | | | | | | | | Using NASM we build OVMF's ResetVector as part of the EDK II build process. v2: * Use EDK II extension of .nasmb rather than .nasmbin Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15823 6f19259b-4bc3-4df7-8a09-765794883524
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-04 23:19:28 +0000