summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* OvmfPkg/XenPlatformPei: Use CPUID to get physical address width on XenIgor Druzhinin2021-01-192-154/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We faced a problem with passing through a PCI device with 64GB BAR to UEFI guest. The BAR is expectedly programmed into 64-bit PCI aperture at 64G address which pushes physical address space to 37 bits. That is above 36-bit width that OVMF exposes currently to a guest without tweaking PcdPciMmio64Size knob. The reverse calculation using this knob was inhereted from QEMU-KVM platform code where it serves the purpose of finding max accessible physical address without necessary trusting emulated CPUID physbits value (that could be different from host physbits). On Xen we expect to use CPUID policy to level the data correctly to prevent situations with guest physbits > host physbits e.g. across migrations. The next aspect raising concern - resource consumption for DXE IPL page tables and time required to map the whole address space in case of using CPUID bits directly. That could be mitigated by enabling support for 1G pages in DXE IPL configuration. 1G pages are available on most CPUs produced in the last 10 years and those without don't have many phys bits. Remove all the redundant code now (including PcdPciMmio64.. handling that's not used on Xen anyway) and grab physbits directly from CPUID that should be what baremetal UEFI systems do. Signed-off-by: Igor Druzhinin <igor.druzhinin@citrix.com> Message-Id: <1610509335-23314-1-git-send-email-igor.druzhinin@citrix.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Julien Grall <julien@xen.org> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com> [lersek@redhat.com: fix up authorship from groups.io-mangled From line] [lersek@redhat.com: wrap commit message at 74 characters]
* UefiCpuPkg/CpuCacheInfoLib: Add new CpuCacheInfoLib.Lou, Yun2021-01-1910-0/+1023
| | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3105 This new library uses a platform agnostic algorithm to get CPU cache information. It provides user with an API(GetCpuCacheInfo) to get detailed CPU cache information by each package, each core type included in this package, and each cache level & type. This library can be used by code that produces SMBIOS_TABLE_TYPE7 SMBIOS table. Signed-off-by: Jason Lou <yun.lou@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com>
* MdePkg/Cpuid.h: Add CPUID_HYBRID_INFORMATION Leaf(1Ah).Jason Lou2021-01-191-1/+62
| | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3105 The UefiCpuPkg/CpuCacheInfoLib will reference new definition about CPUID_HYBRID_INFORMATION Leaf(1Ah). Signed-off-by: Jason Lou <yun.lou@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Cc: Zhiguang Liu <zhiguang.liu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* ArmPlatformPkg/NorFlashDxe: use correct PCD accessorsArd Biesheuvel2021-01-183-8/+9
| | | | | | | | | | | | | | | | | | | | | | Commit 8015f3f6d4005d83 ("ArmPlatformPkg: Enable support for flash in 64-bit address space") updated the NorFlash DXE and StMM drivers to take alternate PCDs into account when discovering the base of the NOR flash regions. This introduced a disparity between the declarations of the PCD references in the .INF files, which permits the use of dynamic PCDs, and the code itself, which now uses FixedPcdGet() accessors. On platforms that actually use dynamic PCDs, this results in a build error. So let's clean this up: - for the DXE version, use the generic PcdGet() accessors, so dynamic PCDs are permitted - for the standalone MM version, redeclare the PCDs as [FixedPcd] in the .INF description, and switch to the FixedPcdGet() accessors. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Vijayenthiran Subramaniam <vijayenthiran.subramaniam@arm.com>
* Maintainers: update Ard's email addressArd Biesheuvel2021-01-181-8/+8
| | | | | | | | | | | | | | | | I will no longer work for ARM as of next month, and will therefore lose access to my @arm.com email account. I intend to remain active in the Tianocore project nonetheless, so let's update my email accounts to one that is not tied to my current or future employer. Cc: <ardb+tianocore@kernel.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Leif Lindholm <leif@nuviainc.com> Reviewed-by: Andrew Fish <afish@apple.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Acked-by: Sami Mujawar <sami.mujawar@arm.com>
* MdeModulePkg/PciBusDxe: Handle BAR sizing fail in high 32bit of MEM64.Zarcd Zhong2021-01-181-0/+1
| | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3149 Address MEM64 BAR in type unknown if sizing fail in high 32bit. Cc: Ray Ni <ray.ni@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Signed-off-by: Zarcd Zhong <zarcd.zhong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* EmulatorPkg/library: RedfishPlatformCredentialLibAbner Chang2021-01-164-1/+299
| | | | | | | | | | | | | | | | Platform specific implementation of acquiring credential to access to Redfish service. This is the platform library which incorporates with Redfish Credential DXE driver under Redfish package. Signed-off-by: Abner Chang <abner.chang@hpe.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Andrew Fish <afish@apple.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Nickle Wang <nickle.wang@hpe.com> Cc: Peter O'Hanley <peter.ohanley@hpe.com> Acked-by: Ray Ni <ray.ni@intel.com>
* MdeModulePkg/FileExplorerLib: Add return value checkwenyi,xie via groups.io2021-01-151-5/+7
| | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3113 According to FAT specification, the length of file path should not larger than 260. When the length exceed 260, function FatLocateOFile will return EFI_INVALID_PARAMETER and the parameter FileHandle will be NULL. Then on the top-level function?an exception happens when the NULL pointer is passed and be used. So adding return value check after calling LibGetFileHandleFromMenu, if return value is not success, stop calling LibFindFiles. Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Dandan Bi <dandan.bi@intel.com> Cc: Eric Dong <eric.dong@intel.com> Signed-off-by: Wenyi Xie <xiewenyi2@huawei.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Dandan Bi <dandan.bi@intel.com>
* NetworkPkg/DxeHttpLib: Migrate HTTP header manipulation APIsAbner Chang2021-01-145-189/+191
| | | | | | | | | | | | | | | | Move HTTP header manipulation functions to DxeHttpLib from HttpBootSupport.c. These general functions are used by both Http BOOT and RedfishLib (patches will be sent later). Signed-off-by: Abner Chang <abner.chang@hpe.com> Cc: Maciej Rabeda <maciej.rabeda@linux.intel.com> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Siyuan Fu <siyuan.fu@intel.com> Cc: Fan Wang <fan.wang@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Nickle Wang <nickle.wang@hpe.com> Cc: Peter O'Hanley <peter.ohanley@hpe.com> Reviewed-by: Maciej Rabeda <maciej.rabeda@linux.intel.com>
* BaseTools: Fix the build report crash issueBob Feng2021-01-141-7/+9
| | | | | | | | | | | | | | | | In the following corner case, the build report will crash. This patch is to fix this problem. Case: Multiple SKU are used and 2 more DynamicHii structure Pcds are set in dsc file under different SKU. And 1 more of those Pcds are not used in any INF file. Signed-off-by: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Yuwei Chen <yuwei.chen@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Yuwei Chen<yuwei.chen@intel.com>
* MdeModulePkg: Update UNI file for PCIe Resizable BAR CapabilityLuo, Heng2021-01-141-1/+7
| | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3138 PcdPcieResizableBarSupport was added in MdeModulePkg.dec, update UNI file as the documentation of the PCD. Cc: Ray Ni <ray.ni@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Signed-off-by: Heng Luo <heng.luo@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* MdeModulePkg: Change default value of PcdPcieResizableBarSupport to FALSELuo, Heng2021-01-141-1/+1
| | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3138 Change default value of PcdPcieResizableBarSupport to FALSE, avoid it impacts existing platforms. Cc: Ray Ni <ray.ni@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Signed-off-by: Heng Luo <heng.luo@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg/CpuDxe: Fix boot errorGuo Dong2021-01-121-5/+3
| | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3084 When DXE drivers are dispatched above 4GB memory in 64bit mode, the address setCodeSelectorLongJump in stack will be override by parameter. Jump to Qword is not supported by some processors. So use "o64 retf" instead. Signed-off-by: Guo Dong <guo.dong@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Tom Lendacky <thomas.lendacky@amd.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Tested-by: James Bottomley <jejb@linux.ibm.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg/MpInitLib: Fix a hang in above 4GB caseGuo Dong2021-01-121-4/+4
| | | | | | | | | | | | This patch fixed the hang in UEFICpuPkg when it is dispatched above 4GB. In UEFI BIOS case CpuInfoInHob is provided to DXE under 4GB from PEI. When using UEFI payload and bootloaders, CpuInfoInHob will be allocated above 4GB since it is not provided from bootloader. so we need update the code to make sure this hob could be accessed correctly in this case. Signed-off-by: Guo Dong <guo.dong@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg PiSmmCpuDxeSmm: Reduce SMRAM consumption in CpuS3.cZeng, Star2021-01-111-17/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch makes two refinements to reduce SMRAM consumption in CpuS3.c. 1. Only do CopyRegisterTable() when register table is not empty, IsRegisterTableEmpty() is created to check whether the register table is empty or not. Take empty PreSmmInitRegisterTable as example, about 24K SMRAM consumption could be reduced when mAcpiCpuData.NumberOfCpus=1024. sizeof (CPU_REGISTER_TABLE) = 24 mAcpiCpuData.NumberOfCpus = 1024 = 1K mAcpiCpuData.NumberOfCpus * sizeof (CPU_REGISTER_TABLE) = 24K 2. Only copy table entries buffer instead of whole buffer. AllocatedSize in SourceRegisterTableList is the whole buffer size. Actually, only the table entries buffer needs to be copied, and the size is TableLength * sizeof (CPU_REGISTER_TABLE_ENTRY). Take AllocatedSize=0x1000=4096, TableLength=100 and NumberOfCpus=1024 as example, about 1696K SMRAM consumption could be reduced. sizeof (CPU_REGISTER_TABLE_ENTRY) = 24 TableLength = 100 TableLength * sizeof (CPU_REGISTER_TABLE_ENTRY) = 2400 AllocatedSize = 0x1000 = 4096 AllocatedSize - TableLength * sizeof (CPU_REGISTER_TABLE_ENTRY) = 4096 - 2400 = 1696 NumberOfCpus = 1024 = 1K NumberOfCpus * (AllocatedSize - TableLength * sizeof (CPU_REGISTER_TABLE_ENTRY)) = 1696K This patch also corrects the CopyRegisterTable() function description. Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Message-Id: <20210111015419.28368-1-star.zeng@intel.com>
* ShellPkg: Remove bogus "Bits" text from some smbiosview strings.Rebecca Cran2021-01-112-3/+3
| | | | | | | | | | | | Neither of the "CPU Socket Unpopulated" or "Do not reboot" messages should contain the word "Bits". Remove them and update the identifier for the "Do not reboot" message to remove the word "BITS". Signed-off-by: Rebecca Cran <rebecca@nuviainc.com> Reviewed-by: Zhichao Gao <zhichao.gao@intel.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
* EmbeddedPkg/RealTimeClockRuntimeDxe: depend on gEfiVariableArchProtocolGuidNhi Pham2021-01-101-1/+1
| | | | | | | | | | | | | | The EfiGetVariable() is used in the entry of this module. So, the variable services are required to be ready before they are used. This patch adds the arch protocol gEfiVariableArchProtocolGuid to dependency expression to guarantee that this module will be started once the variable protocol is available. Cc: Leif Lindholm <leif@nuviainc.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Signed-off-by: Nhi Pham <nhi@os.amperecomputing.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Leif Lindholm <leif@nuviainc.com>
* .pytool: Add required submodule for JsonLibAbner Chang2021-01-091-0/+2
| | | | | | | | | | | | | | Open source project jansson is leveraged by edk2 JsonLib. Add jansson to the required submodule in CiSettings.py. Signed-off-by: Abner Chang <abner.chang@hpe.com> Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Bret Barkelew <Bret.Barkelew@microsoft.com> Cc: Nickle Wang <nickle.wang@hpe.com> Cc: Peter O'Hanley <peter.ohanley@hpe.com> Reviewed-by: Bret Barkelew <Bret.Barkelew@microsoft.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
* RedfishPkg: Add EDK2 port of jansson library to buildAbner Chang2021-01-092-0/+2
| | | | | | | | | | | Add EDK2 port jansson library (JsonLib) to RedfishPkg Signed-off-by: Abner Chang <abner.chang@hpe.com> Cc: Nickle Wang <nickle.wang@hpe.com> Cc: Peter O'Hanley <peter.ohanley@hpe.com> Reviewed-by: Nickle Wang <nickle.wang@hpe.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
* RedfishPkg/library: EDK2 port of jansson libraryAbner Chang2021-01-099-1/+3047
| | | | | | | | | | | | | | | | | edk2 JsonLib which is the edk2 port of open source jansson library. (https://github.com/akheron/jansson) jansson library is the open source project to manipulate JSON data structure. Signed-off-by: Abner Chang <abner.chang@hpe.com> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Nickle Wang <nickle.wang@hpe.com> Cc: Peter O'Hanley <peter.ohanley@hpe.com> Reviewed-by: Nickle Wang <nickle.wang@hpe.com> Acked-by: Leif Lindholm <leif@nuviainc.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
* RedfishPkg/RedfishCrtLib: Redfish C runtime libraryAbner Chang2021-01-0919-0/+1310
| | | | | | | | | | | | | | | | | Redfish CRT library is currently used by edk2 JsonLib (open source jansson project) and edk2 RedfishLib (libredfish open source project). Redfish CrtLib library provides the necessary C runtime equivalent edk2 functions for open source projects. Signed-off-by: Abner Chang <abner.chang@hpe.com> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Nickle Wang <nickle.wang@hpe.com> Cc: Peter O'Hanley <peter.ohanley@hpe.com> Reviewed-by: Nickle Wang <nickle.wang@hpe.com> Acked-by: Leif Lindholm <leif@nuviainc.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
* edk2: jansson submodule for edk2 JSON libraryAbner Chang2021-01-093-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | Add git submodule "jansson" library, which is the open source project (https://github.com/akheron/jansson) used to manipulate JSON data structure. jansson library is wrapped as edk2 JsonLib and the use cases will be the edk2 Redfish feature drivers and edk2 port of libredfish (https://github.com/DMTF/libredfish). jansson open source project is under MIT license. (refer to ReadMe.rst under edk2). Signed-off-by: Abner Chang <abner.chang@hpe.com> Cc: Andrew Fish <afish@apple.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Nickle Wang <nickle.wang@hpe.com> Cc: Peter O'Hanley <peter.ohanley@hpe.com> Reviewed-by: Nickle Wang <nickle.wang@hpe.com> Acked-by: Leif Lindholm <leif@nuviainc.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
* RedfishPkg/Ucs2Utf8lib: UCS2 to UFT8 manipulation libraryAbner Chang2021-01-096-0/+519
| | | | | | | | | | | | | | | | This library provides UCS2 to UFT8 or vise versa functions to manipulate UCS2/UTF8 strings. This library is currently used by edk2 port of open source jansson library. Signed-off-by: Abner Chang <abner.chang@hpe.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Nickle Wang <nickle.wang@hpe.com> Cc: Peter O'Hanley <peter.ohanley@hpe.com> Reviewed-by: Nickle Wang <nickle.wang@hpe.com> Acked-by: Leif Lindholm <leif@nuviainc.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
* OvmfPkg: add TimeBaseLib resolution for OvmfXenLeif Lindholm2021-01-081-0/+1
| | | | | | | | | | | | | | | | Commit 55ee36b0c490 ("EmbeddedPkg/RealTimeClockRuntimeDxe: Use helper functions from TimeBaseLib") added a TimeBaseLib dependency to RealTimeClockRuntimeDxe, which now breaks build of OvmfXen.dsc. Add a resolution for EmbeddedPkg/Library/TimeBaseLib/TimeBaseLib.inf. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien@xen.org> Signed-off-by: Leif Lindholm <leif@nuviainc.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* EmbeddedPkg: add TimeBaseLib resolution to EmbeddedPkg.dscLeif Lindholm2021-01-081-0/+2
| | | | | | | | | | | | | | Commit 55ee36b0c490 ("EmbeddedPkg/RealTimeClockRuntimeDxe: Use helper functions from TimeBaseLib") added a TimeBaseLib dependency to RealTimeClockRuntimeDxe, which now breaks build of EmbeddedPkg.dsc. Add a resolution for EmbeddedPkg/Library/TimeBaseLib/TimeBaseLib.inf. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Nhi Pham <nhi@os.amperecomputing.com> Signed-off-by: Leif Lindholm <leif@nuviainc.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* EmbeddedPkg/PrePiMemoryAllocationLib: use correct size for pool hobArd Biesheuvel2021-01-081-1/+3
| | | | | | | | | Use the correct type in the sizeof() expression to calculate the size of the newly allocated EFI_HOB_MEMORY_POOL hob. Link: https://bugzilla.tianocore.org/show_bug.cgi?id=3139 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Leif Lindholm <leif@nuviainc.com>
* MdeModulePkg Lzma: Update LZMA SDK version to 19.00Liu, WeiX C2021-01-0811-78/+163
| | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3101 New formal release in https://www.7-zip.org/sdk.html is 19.00. Cc: Liming Gao <gaoliming@byosoft.com.cn> Signed-off-by: Wei Liu <weix.c.liu@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* BaseTools LzmaCompress: Update LZMA to new 19.00 versionLiu, WeiX C2021-01-0812-575/+877
| | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3101 New formal release in https://www.7-zip.org/sdk.html is 19.00. Cc: Liming Gao <gaoliming@byosoft.com.cn> Signed-off-by: Wei Liu <weix.c.liu@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* ShellPkg/Acpiview: AEST ParserMarc Moisson-Franckhauser2021-01-085-1/+781
| | | | | | | | | | | | | | | | | Bugzilla: 3048 (https://bugzilla.tianocore.org/show_bug.cgi?id=3048) Add a new parser for the Arm Error Source Table (AEST) described in the ACPI for the Armv8 RAS Extensions 1.1 Platform Design Document, dated 28 September 2020. (https://developer.arm.com/documentation/den0085/0101/) AEST enables kernel-first handling of errors in a system that supports the Armv8 RAS extensions. It covers Armv8.2+ RAS extensions for PEs and the RAS system architecture for non-PE system components. Signed-off-by: Marc Moisson-Franckhauser <marc.moisson-franckhauser@arm.com> Signed-off-by: Sami Mujawar <sami.mujawar@arm.com> Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
* MdePkg/IndustryStandard: AEST Table definitionMarc Moisson-Franckhauser2021-01-081-0/+357
| | | | | | | | | | | | | | Bugzilla: 3049 (https://bugzilla.tianocore.org/show_bug.cgi?id=3049) Add definition for the Arm Error Source Table (AEST) described in the ACPI for the Armv8 RAS Extensions 1.1 Platform Design Document, dated 28 September 2020. (https://developer.arm.com/documentation/den0085/0101/) Signed-off-by: Marc Moisson-Franckhauser <marc.moisson-franckhauser@arm.com> Signed-off-by: Sami Mujawar <sami.mujawar@arm.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
* OvfmPkg/VmgExitLib: Validate #VC MMIO is to un-encrypted memoryTom Lendacky2021-01-076-1/+88
| | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108 When SEV-ES is active, and MMIO operation will trigger a #VC and the VmgExitLib exception handler will process this MMIO operation. A malicious hypervisor could try to extract information from encrypted memory by setting a reserved bit in the guests nested page tables for a non-MMIO area. This can result in the encrypted data being copied into the GHCB shared buffer area and accessed by the hypervisor. Prevent this by ensuring that the MMIO source/destination is un-encrypted memory. For the APIC register space, access is allowed in general. 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> Acked-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <0cf28470ad5e694af45f7f0b35296628f819567d.1610045305.git.thomas.lendacky@amd.com>
* OvmfPkg/PlatformPei: Reserve GHCB backup pages if S3 is supportedTom Lendacky2021-01-072-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108 Protect the GHCB backup pages used by an SEV-ES guest when S3 is supported. Regarding the lifecycle of the GHCB backup pages: PcdOvmfSecGhcbBackupBase (a) when and how it is initialized after first boot of the VM If SEV-ES is enabled, the GHCB backup pages are initialized when a nested #VC is received during the SEC phase [OvmfPkg/Library/VmgExitLib/SecVmgExitVcHandler.c]. (b) how it is protected from memory allocations during DXE If S3 and SEV-ES are enabled, then InitializeRamRegions() [OvmfPkg/PlatformPei/MemDetect.c] protects the ranges with an AcpiNVS memory allocation HOB, in PEI. If S3 is disabled, then these ranges are not protected. PEI switches to the GHCB backup pages in permanent PEI memory and DXE will use these PEI GHCB backup pages, so we don't have to preserve PcdOvmfSecGhcbBackupBase. (c) how it is protected from the OS If S3 is enabled, then (b) reserves it from the OS too. If S3 is disabled, then the range needs no protection. (d) how it is accessed on the S3 resume path It is rewritten same as in (a), which is fine because (b) reserved it. (e) how it is accessed on the warm reset path It is rewritten same as in (a). Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien@xen.org> 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: <119102a3d14caa70d81aee334a2e0f3f925e1a60.1610045305.git.thomas.lendacky@amd.com>
* OvmfPkg/VmgExitLib: Support nested #VCsTom Lendacky2021-01-0713-27/+404
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108 In order to be able to issue messages or make interface calls that cause another #VC (e.g. GetLocalApicBaseAddress () issues RDMSR), add support for nested #VCs. In order to support nested #VCs, GHCB backup pages are required. If a #VC is received while currently processing a #VC, a backup of the current GHCB content is made. This allows the #VC handler to continue processing the new #VC. Upon completion of the new #VC, the GHCB is restored from the backup page. The #VC recursion level is tracked in the per-vCPU variable area. Support is added to handle up to one nested #VC (or two #VCs total). If a second nested #VC is encountered, an ASSERT will be issued and the vCPU will enter CpuDeadLoop (). For SEC, the GHCB backup pages are reserved in the OvmfPkgX64.fdf memory layout, with two new fixed PCDs to provide the address and size of the backup area. For PEI/DXE, the GHCB backup pages are allocated as boot services pages using the memory allocation library. 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> Acked-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <ac2e8203fc41a351b43f60d68bdad6b57c4fb106.1610045305.git.thomas.lendacky@amd.com>
* OvmfPkg/MemEncryptSevLib: Address range encryption state interfaceTom Lendacky2021-01-0710-12/+368
| | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108 Update the MemEncryptSevLib library to include an interface that can report the encryption state on a range of memory. The values will represent the range as being unencrypted, encrypted, a mix of unencrypted and encrypted, and error (e.g. ranges that aren't mapped). 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> Acked-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <0d98f4d42a2b67310c29bac7bcdcf1eda6835847.1610045305.git.thomas.lendacky@amd.com>
* OvmfPkg/MemEncryptSevLib: Make the MemEncryptSevLib available for SECTom Lendacky2021-01-077-4/+289
| | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108 In preparation for a new interface to be added to the MemEncryptSevLib library that will be used in SEC, create an SEC version of the library. This requires the creation of SEC specific files. Some of the current MemEncryptSevLib functions perform memory allocations which cannot be performed in SEC, so these interfaces will return an error during SEC. Also, the current MemEncryptSevLib library uses some static variables to optimize access to variables, which cannot be used in SEC. 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> Acked-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <bc7fa76cc23784ab3f37356b6c10dfec61942c38.1610045305.git.thomas.lendacky@amd.com>
* OvmfPkg/MemEncryptSevLib: Coding style fixes in prep for SEC libraryTom Lendacky2021-01-071-6/+6
| | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108 Creating an SEC version of the library requires renaming an existing file which will result in the existing code failing ECC. Prior to renaming the existing file, fix the coding style to avoid the ECC failure. 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: <f765d867da4a703e0a0db35e26515a911482fd40.1610045305.git.thomas.lendacky@amd.com>
* OvmfPkg/VmgExitLib: Check for an explicit DR7 cached valueTom Lendacky2021-01-071-4/+7
| | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108 Check the DR7 cached indicator against a specific value. This makes it harder for a hypervisor to just write random data into that field in an attempt to use an invalid DR7 value. 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: <65157c1155a9c058c43678400dfc0b486e327a3e.1610045305.git.thomas.lendacky@amd.com>
* OvmfPkg/AmdSevDxe: Clear encryption bit on PCIe MMCONFIG rangeTom Lendacky2021-01-072-2/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108 The PCIe MMCONFIG range should be treated as an MMIO range. However, there is a comment in the code explaining why AddIoMemoryBaseSizeHob() is not called. The AmdSevDxe walks the GCD map looking for MemoryMappedIo or NonExistent type memory and will clear the encryption bit for these ranges. Since the MMCONFIG range does not have one of these types, the encryption bit is not cleared for this range. Add support to detect the presence of the MMCONFIG range and clear the encryption bit. This will be needed for follow-on support that will validate that MMIO is not being performed to an encrypted address range under SEV-ES. Even though the encryption bit was set for this range, this still worked under both SEV and SEV-ES because the address range is marked by the hypervisor as MMIO in the nested page tables: - For SEV, access to this address range triggers a nested page fault (NPF) and the hardware supplies the guest physical address (GPA) in the VMCB's EXITINFO2 field as part of the exit information. However, the encryption bit is not set in the GPA, so the hypervisor can process the request without any issues. - For SEV-ES, access to this address range triggers a #VC. Since OVMF runs identity mapped (VA == PA), the virtual address is used to avoid the lookup of the physical address. The virtual address does not have the encryption bit set, so the hypervisor can process the request without any issues. 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: <711ae2dcb6cb29e4c60862c18330cff627269b81.1610045305.git.thomas.lendacky@amd.com>
* OvmfPkg: Obtain SEV encryption mask with the new MemEncryptSevLib APITom Lendacky2021-01-074-40/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. The new MemEncryptSevGetEncryptionMask() interface provides access to this validated value. To ensure that we always use a validated encryption mask for an SEV-ES guest, update all locations that use CPUID to calculate the encryption mask to use the new interface. Also, clean up some call areas where extra masking was being performed and where a function call was being used instead of the local variable that was just set using the function. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Peter Grehan <grehan@freebsd.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien@xen.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <9de678c0d66443c6cc33e004a4cac0a0223c2ebc.1610045305.git.thomas.lendacky@amd.com>
* OvmfPkg/MemEncryptSevLib: Add an interface to retrieve the encryption maskTom Lendacky2021-01-0712-104/+400
| | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108 To ensure that we always use a validated encryption mask for an SEV-ES guest, create a new interface in the MemEncryptSevLib library to return the encryption mask. This can be used in place of the multiple locations where CPUID is used to retrieve the value (which would require validation again) and allows the validated mask to be returned. The PEI phase will use the value from the SEV-ES work area. Since the SEV-ES work area isn't valid in the DXE phase, the DXE phase will use the PcdPteMemoryEncryptionAddressOrMask PCD which is set during PEI. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Peter Grehan <grehan@freebsd.org> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien@xen.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <e12044dc01b21e6fc2e9535760ddf3a38a142a71.1610045305.git.thomas.lendacky@amd.com>
* OvmfPkg/ResetVector: Save the encryption mask at boot timeTom Lendacky2021-01-073-1/+12
| | | | | | | | | | | | | | | | | | 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-074-3/+136
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* OvmfPkg/Sec: Move SEV-ES SEC workarea definition to common header fileTom Lendacky2021-01-072-5/+17
| | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108 In order to allow for the SEV-ES workarea to be used for other purposes and by other files, move the definition into the BaseMemEncryptSevLib header file, MemEncryptSevLib.h. 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: <07d66f3384bd54da97d540e89b9f3473a6d17231.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>
* EmbeddedPkg/RealTimeClockRuntimeDxe: Use helper functions from TimeBaseLibNhi Pham2021-01-072-86/+4
| | | | | | | | | | This patch replaces all time checking functions and leverage the helper functions in TimeBaseLib library. Cc: Leif Lindholm <leif@nuviainc.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Signed-off-by: Nhi Pham <nhi@os.amperecomputing.com> Reviewed-by: Leif Lindholm <leif@nuviainc.com>
* EmbeddedPkg/TimeBaseLib: Add function to check Timezone and DaylightNhi Pham2021-01-072-2/+83
| | | | | | | | | | | | This adds two functions IsValidTimeZone() and IsValidDaylight() to check the time zone and daylight value from EFI time. These functions are retrieved from the RealTimeClockRuntimeDxe module as they reduce duplicated code in RTC modules. Cc: Leif Lindholm <leif@nuviainc.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Signed-off-by: Nhi Pham <nhi@os.amperecomputing.com> Reviewed-by: Leif Lindholm <leif@nuviainc.com>
* EmbeddedPkg/TimeBaseLib: Fix for minor code formattingNhi Pham2021-01-071-12/+11
| | | | | | | | | There is no functional modification in this change. Cc: Leif Lindholm <leif@nuviainc.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Signed-off-by: Nhi Pham <nhi@os.amperecomputing.com> Reviewed-by: Leif Lindholm <leif@nuviainc.com>
* EmbeddedPkg/TimeBaseLib: Update comment blocks for API functionsNhi Pham2021-01-072-14/+104
| | | | | | | | | This updates Doxygen comment blocks for API library functions. Cc: Leif Lindholm <leif@nuviainc.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Signed-off-by: Nhi Pham <nhi@os.amperecomputing.com> Reviewed-by: Leif Lindholm <leif@nuviainc.com>
* ArmPlatformPkg: Enable support for flash in 64-bit address spaceVijayenthiran Subramaniam2021-01-075-23/+92
| | | | | | | | | | | | | The existing NOR Flash DXE and StandaloneMm driver supports NOR flash devices connected in the 32-bit address space. Extend these drivers to allow NOR flash devices connected to 64-bit address space to be usable as well. Also, convert the base address and size sanity check from ASSERT() to if condition so that even if the firmware is build in release mode, it can return error if the parameter(s) is/are invalid. Signed-off-by: Vijayenthiran Subramaniam <vijayenthiran.subramaniam@arm.com> Tested-by: Masahisa Kojima <masahisa.kojima@linaro.org> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
generated by cgit v1.2.3 (git 2.25.1) at 2025-02-16 18:45:33 +0000