summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* RedfishPkg/RedfishPlatformConfigDxe: fix can not set one-of option issue.Nickle Wang2023-09-131-6/+5
| | | | | | | | | | | StatementValue->Buffer is converted from ASCII to Unicode by caller already so we don't have to convert it again. Signed-off-by: Nickle Wang <nicklew@nvidia.com> Cc: Abner Chang <abner.chang@amd.com> Cc: Igor Kulchytskyy <igork@ami.com> Cc: Nick Ramirez <nramirez@nvidia.com> Reviewed-by: Igor Kulchytskyy <igork@ami.com>
* OvmfPkg/TdxDxe: Change MadtMpWk->MailBoxVersion from 1 to 0Min M Xu2023-09-131-1/+1
| | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4527 According to ACPI 6.5 (https://uefi.org/specs/ACPI/6.5/05_ACPI_Software _Programming_Model.html?highlight=mailboxversion#multiprocessor-wakeup- structure) the MailBoxVersion is 0. This patch changed MadtMpWk->MailBoxVersion from 1 to 0 to fix the error. Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Michael Roth <michael.roth@amd.com> Signed-off-by: Min Xu <min.m.xu@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* Maintainers.txt: Make myself maintainer for OvmfPkg/RiscVVirtSunil V L2023-09-121-1/+1
| | | | | | | | | Since I take care of maintaining the contents in RiscVVirt, update my entry from R to M. Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
* OvmfPkg: raise DXEFV size to 14.5 MB in the traditional platform FDFsLaszlo Ersek2023-09-123-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | My usual IA32X64 and X64 builds fail for the NOOPT target, using GCC5: - IA32X64: > the required fv image size 0xdef130 exceeds the set fv image size > 0xd00000 - X64: > the required fv image size 0xd8f7b8 exceeds the set fv image size > 0xd00000 NOOPT is important for debugging (less confusing behavior with gdb, and much less confusing disassembly). Raise the DXEFV size to 14.5 MB (14 MB would work, but cut it too close for IA32X64). After this patch: - IA32: > DXEFV [83%Full] 15204352 (0xe80000) total, 12718784 (0xc212c0) used, > 2485568 (0x25ed40) free - IA32X64: > DXEFV [96%Full] 15204352 (0xe80000) total, 14610736 (0xdef130) used, > 593616 (0x90ed0) free - X64: > DXEFV [93%Full] 15204352 (0xe80000) total, 14219192 (0xd8f7b8) used, > 985160 (0xf0848) free Tested with: - IA32, q35, SMM_REQUIRE, Fedora 30 guest - X64, pc (i440fx), no SMM, RHEL-7.9 guest - IA32X64, q35, SMM_REQUIRE, RHEL-7.9 guest Test steps (IA32 and X64): - configure 3 VCPUs - boot - run "taskset -c $I efibootmgr" with $I covering 0..2 - systemctl suspend - resume from virt-manager - run "taskset -c $I efibootmgr" with $I covering 0..2 Test steps (IA32X64): - same, but - start with only 2 cold-plugged CPUs, and - hot-plug the third VCPU after initial (cold) boot, before the first "taskset -c $I efibootmgr" invocation Also compared the verbose IA32 fw log from before the patch vs. the one after (because IA32 builds even without this patch); the changes look sane: > @@ -1,6 +1,6 @@ > SecCoreStartupWithStack(0xFFFCC000, 0x820000) > SEC: Normal boot > -DecompressMemFvs: OutputBuffer@A00000+0xDE0090 ScratchBuffer@1800000+0x10000 PcdOvmfDecompressionScratchEnd=0x1810000 > +DecompressMemFvs: OutputBuffer@A00000+0xF60090 ScratchBuffer@1A00000+0x10000 PcdOvmfDecompressionScratchEnd=0x1A10000 > Register PPI Notify: [EfiPeiSecurity2Ppi] > Install PPI: [EfiFirmwareFileSystem2] > Install PPI: [EfiFirmwareFileSystem3] > @@ -28,7 +28,7 @@ > Loading PEIM at 0x000008490C0 EntryPoint=0x0000085639A PlatformPei.efi > Platform PEIM Loaded > CMOS: > -00: 10 00 30 00 13 00 03 12 09 23 26 02 00 80 00 00 > +00: 20 00 41 00 13 00 03 12 09 23 26 02 00 80 00 00 > 10: 00 00 00 00 06 80 02 FF FF 00 00 00 00 00 00 00 > 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 30: FF FF 20 00 00 7F 00 20 30 00 00 00 00 12 00 00 > @@ -70,7 +70,7 @@ > Platform PEI Firmware Volume Initialization > Install PPI: [EfiPeiFirmwareVolumeInfoPpi] > Notify: PPI Guid: [EfiPeiFirmwareVolumeInfoPpi], Peim notify entry point: 826554 > -The 1th FV start address is 0x00000900000, size is 0x00D00000, handle is 0x900000 > +The 1th FV start address is 0x00000900000, size is 0x00E80000, handle is 0x900000 > Register PPI Notify: [EfiPeiReadOnlyVariable2Ppi] > Select Item: 0x19 > Select Item: 0x26 > @@ -90,8 +90,8 @@ > Memory Allocation 0x00000000 0x7F000000 - 0x7FFFFFFF > Memory Allocation 0x00000000 0x30000 - 0x4FFFF > Memory Allocation 0x0000000A 0x820000 - 0x8FFFFF > -Memory Allocation 0x0000000A 0x900000 - 0x15FFFFF > -Memory Allocation 0x0000000A 0x1600000 - 0x180FFFF > +Memory Allocation 0x0000000A 0x900000 - 0x177FFFF > +Memory Allocation 0x0000000A 0x1780000 - 0x1A0FFFF > Memory Allocation 0x00000000 0xE0000000 - 0xEFFFFFFF > Old Stack size 32768, New stack size 131072 > Stack Hob: BaseAddress=0x7AF68000 Length=0x20000 > @@ -196,8 +196,8 @@ > Memory Allocation 0x00000000 0x7F000000 - 0x7FFFFFFF > Memory Allocation 0x00000000 0x30000 - 0x4FFFF > Memory Allocation 0x0000000A 0x820000 - 0x8FFFFF > -Memory Allocation 0x0000000A 0x900000 - 0x15FFFFF > -Memory Allocation 0x0000000A 0x1600000 - 0x180FFFF > +Memory Allocation 0x0000000A 0x900000 - 0x177FFFF > +Memory Allocation 0x0000000A 0x1780000 - 0x1A0FFFF > Memory Allocation 0x00000000 0xE0000000 - 0xEFFFFFFF > Memory Allocation 0x00000004 0x7EE50000 - 0x7EE6FFFF > Memory Allocation 0x00000003 0x7EF50000 - 0x7EF67FFF > @@ -219,7 +219,7 @@ > Memory Allocation 0x00000003 0x7EE70000 - 0x7EEB2FFF > Memory Allocation 0x00000004 0x7EE50000 - 0x7EE6FFFF > Memory Allocation 0x00000004 0x7AF68000 - 0x7AF87FFF > -FV Hob 0x900000 - 0x15FFFFF > +FV Hob 0x900000 - 0x177FFFF > InstallProtocolInterface: [EfiDecompressProtocol] 7EEAAA54 > InstallProtocolInterface: [EfiFirmwareVolumeBlockProtocol|EfiFirmwareVolumeBlock2Protocol] 7EB3491C > InstallProtocolInterface: [EfiDevicePathProtocol] 7EB34990 > @@ -3259,7 +3259,7 @@ > UefiMemory protection: 0x50000 - 0x9E000 Success > UefiMemory protection: 0x100000 - 0x807000 Success > UefiMemory protection: 0x808000 - 0x810000 Success > -UefiMemory protection: 0x1810000 - 0x7AF88000 Success > +UefiMemory protection: 0x1A10000 - 0x7AF88000 Success > UefiMemory protection: 0x7AF8B000 - 0x7EB3D000 Success > UefiMemory protection: 0x7EDBD000 - 0x7EDCF000 Success > UefiMemory protection: 0x7EE4F000 - 0x7EF68000 Success Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg/PlatformBootManagerLib: refer to virtio console subsys symbolicallyLaszlo Ersek2023-09-121-1/+1
| | | | | | | | | | | "OvmfPkg/Include/IndustryStandard/Virtio095.h" defines the macro VIRTIO_SUBSYSTEM_CONSOLE with value 3; other locations in the tree already use it (such as ArmVirtPkg/PlatformBootManagerLib, OvmfPkg/VirtioSerialDxe). We should use it in OvmfPkg/PlatformBootManagerLib too, rather than the naked constant 3. Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Ard Biesheuvel <ardb@kernel.org>
* ArmPkg/ArmMmuLib: Drop buggy secure memory type checkArd Biesheuvel2023-09-122-4/+0
| | | | | | | | | | | | | | | Jake reports that the IS_ARM_MEMORY_REGION_ATTRIBUTES_SECURE() macro is no longer accurate since commit 852227a9d52e3cb9 ("ArmPkg/Mmu: Remove handling of NONSECURE memory regions"). Fortunately, it only affects the NS bit in level 1 short descriptors, which is ignored when executing in non-secure mode. And given that running UEFI in the secure world is not a use case we aim to support, let's just drop this logic altogether. Reported-by: Jake Garver <jake@nvidia.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
* OvmfPkg/RiscVVirt/README.md: bring your own OpenSBILaszlo Ersek2023-09-121-0/+17
| | | | | | | | | | | | | | Explain how users can compose their pre-OS environment purely from binaries they've built themselves. Cc: Andrei Warkentin <andrei.warkentin@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Sunil V L <sunilvl@ventanamicro.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
* MdeModulePkg/BootMaintenanceManagerUiLib: Check array index before accessMichael Kubacki2023-09-121-4/+7
| | | | | | | | | | | | | | | | | | | | | | Many arrays are defined with a length of MAX_MENU_NUMBER in FormGuid.h. Two of those are BootOptionOrder and DriverOptionOrder. In UpdatePage.c, a pointer is set to either of those arrays. The array buffer is accessed using an index whose range is checked after the pointer to the array is dereferenced. This change moves the check before the dereference. In another place in the file, the ConsoleCheck pointer is also set to an array buffer with MAX_MENU_NUMBER elements. Only an ASSERT() currently checks the range of the array index. This change conditionalizes the pointer dereference itself on the range of Index. Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Dandan Bi <dandan.bi@intel.com> Cc: Eric Dong <eric.dong@intel.com> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Dandan Bi <dandan.bi@intel.com>
* Maintainers.txt: Update reviewers and maintainers for DynamicTablesPkgPierre Gondois2023-09-111-2/+1
| | | | | | | | Update reviewers and maintainers for DynamicTablesPkg Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
* MdeModulePkg/Core/Dxe: Fix memory leak issue in FwVolBlock.cMike Maslenkin2023-09-111-0/+2
| | | | | | | | | | | FvbDev->LbaCache must be freed on error path before freeing FvbDev. Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Dandan Bi <dandan.bi@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Signed-off-by: Mike Maslenkin <mike.maslenkin@gmail.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdeModulePkg/Core/Dxe: Fix memory leak issue in FwVol.cMike Maslenkin2023-09-111-0/+1
| | | | | | | | | | | FwVolHeader must be freed on error path. Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Dandan Bi <dandan.bi@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Signed-off-by: Mike Maslenkin <mike.maslenkin@gmail.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* MdeModulePkg/HiiDatabase: Fix incorrect AllocateCopyPool sizeMike Beaton2023-09-111-1/+1
| | | | | | | | | | | | | | | | | | The immediately preceding call, GetBestLanguage, plus the implementation of HiiGetString, which is called immediately afterwards, make it clear that BestLanguage is a null-terminated ASCII string, and not just a five byte, non-null terminated buffer. Therefore AsciiStrLen is one byte too short, meaning that whether the space allocated is really sufficient and whether the resultant string is really null-terminated becomes implementation-dependent. Rather than switching to AsciiStrSize, we use an explicitly compile-time string length calculation (both compile-time and run-time approaches are currently used elsewhere in the codebase for copying static strings). Signed-off-by: Mike Beaton <mjsbeaton@gmail.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Dandan Bi <dandan.bi@intel.com>
* NetworkPkg: Increase HTTP buffer size and enable TCP window scalingAndrei Otcheretianski2023-09-083-25/+27
| | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4505 This gives something like ~3 fold throughput boost. Cc: Saloni Kasbekar <saloni.kasbekar@intel.com> Cc: Zachary Clark-williams <zachary.clark-williams@intel.com> Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com> Reviewed-by: Saloni Kasbekar <saloni.kasbekar@intel.com> Acked-by: Michael D Kinney <michael.d.kinney@intel.com>
* MdePkg/SmBios.h: Add New Intel Processor familyAvinash Bhargava2023-09-081-0/+1
| | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4547 Add New Intel Processor family for SMBIOS Type 4 Hex value - 16h Name - Intel(R) Processor Cc: Zhiguang Liu <zhiguang.liu@intel.com> Cc: Dandan Bi <dandan.bi@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Zhichao Gao <zhichao.gao@intel.com> Cc: Benny Lin <benny.lin@intel.com> Cc: Gua Guo <gua.guo@intel.com> Cc: Prakashan Krishnadas Veliyathuparambil <krishnadas.veliyathuparambil.prakashan@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Signed-off-by: Avinash Bhargava <avinash.bhargava@intel.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
* Add a .editorconfig file to tell editors basic formatting detailsRebecca Cran2023-09-081-0/+31
| | | | | | | | | Add a .editorconfig file which editors can use for basic formatting details of files, such as tabs/spaces, line endings etc. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Michael D Kinney <michael.d.kinney@intel.com>
* OvmfPkg/Bhyve: don't exit early if RSDP is not found in memoryCorvin Köhne2023-09-081-11/+8
| | | | | | | | | | | | | | If OVMF fails to find the RSDP in memory, it should fall back installing the statically provided ACPI tables. Signed-off-by: Corvin Köhne <corvink@FreeBSD.org> 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: Rebecca Cran <rebecca@bsdio.com> Cc: Peter Grehan <grehan@freebsd.org> Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
* ShellPkg/UefiShellNetwork2CommandsLib: Check array index before accessMichael Kubacki2023-09-081-1/+1
| | | | | | | | | | | | Moves the range check for the index into the array before attempting any accesses using the array index. Cc: Zhichao Gao <zhichao.gao@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
* MdePkg/Library/TdxLib: Remove unnecessary comparisonMichael Kubacki2023-09-081-1/+1
| | | | | | | | | | | | | | | | | Removes the comparison since unsigned values are always greater than or equal to 0. See the following CodeQL query for more info: /cpp/cpp-unsigned-comparison-zero/ Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Zhiguang Liu <zhiguang.liu@intel.com> Cc: Rebecca Cran <rebecca@bsdio.com> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
* SecurityPkg: RngDxe: Fixing mAvailableAlgoArray allocatorKun Qin2023-09-082-2/+2
| | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?idD91 mAvailableAlgoArray is currently allocated for "RNG_AVAILABLE_ALGO_MAX" number of bytes, whereas it was dereferenced as "EFI_RNG_ALGORITHM". This change fixed the buffer allocation logic by allocating a proper size of buffer before referencing. Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Sami Mujawar <Sami.Mujawar@arm.com> Cc: Pierre Gondois <pierre.gondois@arm.com> Signed-off-by: Kun Qin <kuqin@microsoft.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
* SecurityPkg/RngDxe: Simplify Rng algorithm selection for ArmPierre Gondois2023-09-081-13/+4
| | | | | | | | | | | | The first element of mAvailableAlgoArray is defined as the default Rng algorithm to use. Don't go through the array at each RngGetRNG() call and just return the first element of the array. Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Tested-by: Kun Qin <kun.qin@microsoft.com>
* SecurityPkg/RngDxe: Use GetRngGuid() when probing RngLibPierre Gondois2023-09-083-21/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4151 The EFI_RNG_PROTOCOL can rely on the RngLib. The RngLib has multiple implementations, some of them are unsafe (e.g. BaseRngLibTimerLib). To allow the RngDxe to detect when such implementation is used, a GetRngGuid() function was added in a previous patch. The EFI_RNG_PROTOCOL can advertise multiple algorithms through Guids. The PcdCpuRngSupportedAlgorithm is currently used to advertise the RngLib in the Arm implementation. The issues of doing that are: - the RngLib implementation might not use CPU instructions, cf. the BaseRngLibTimerLib - most platforms don't set PcdCpuRngSupportedAlgorithm A GetRngGuid() was added to the RngLib in a previous patch, allowing to identify the algorithm implemented by the RngLib. Make use of this function and place the unsage algorithm at the last position in the mAvailableAlgoArray. Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Tested-by: Kun Qin <kun.qin@microsoft.com>
* MdePkg/Rng: Add GetRngGuid() to RngLibPierre Gondois2023-09-089-0/+200
| | | | | | | | | | | | | The EFI_RNG_PROTOCOL can use the RngLib. The RngLib has multiple implementations, some of them are unsafe (e.g. BaseRngLibTimerLib). To allow the RngDxe to detect when such implementation is used, add a GetRngGuid() function to the RngLib. Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Tested-by: Kun Qin <kun.qin@microsoft.com>
* MdeModulePkg/Rng: Add GUID to describe unsafe Rng algorithmsPierre Gondois2023-09-082-0/+26
| | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4441 The EFI_RNG_PROTOCOL can rely on the RngLib. The RngLib has multiple implementations, some of them are unsafe (e.g. BaseRngLibTimerLib). To allow the RngDxe to detect when such implementation is used, a GetRngGuid() function is added in a following patch. Prepare GetRngGuid() return values and add a gEdkiiRngAlgorithmUnSafe to describe an unsafe implementation, cf. the BaseRngLibTimerLib. Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Tested-by: Kun Qin <kun.qin@microsoft.com>
* MdePkg/Rng: Add GUID to describe Arm Rndr Rng algorithmsPierre Gondois2023-09-082-0/+11
| | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4441 The EFI_RNG_PROTOCOL can rely on the RngLib. The RngLib has multiple implementations, some of them are unsafe (e.g. BaseRngLibTimerLib). To allow the RngDxe to detect when such implementation is used, a GetRngGuid() function is added in a following patch. Prepare GetRngGuid() return values and add a gEfiRngAlgorithmArmRndr to describe a Rng algorithm accessed through Arm's RNDR instruction. [1] states that the implementation of this algorithm should be compliant to NIST SP900-80. The compliance is not guaranteed. [1] Arm Architecture Reference Manual Armv8, for A-profile architecture sK12.1 'Properties of the generated random number' Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Acked-by: Ard Biesheuvel <ardb@kernel.org> Tested-by: Kun Qin <kun.qin@microsoft.com>
* MdePkg/DxeRngLib: Request raw algorithm instead of defaultPierre Gondois2023-09-081-1/+7
| | | | | | | | | | | | | | | | The DxeRngLib tries to generate a random number using the 3 NIST SP 800-90 compliant DRBG algorithms, i.e. 256-bits CTR, HASH and HMAC. If none of the call is successful, the fallback option is the default RNG algorithm of the EFI_RNG_PROTOCOL. This default algorithm might be an unsafe implementation. Try requesting the Raw algorithm before requesting the default one. Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Acked-by: Ard Biesheuvel <ardb@kernel.org> Tested-by: Kun Qin <kun.qin@microsoft.com>
* SecurityPkg/SecurityPkg.dec: Move PcdCpuRngSupportedAlgorithm to MdePkgPierre Gondois2023-09-084-5/+8
| | | | | | | | | | | | | | | | In order to use PcdCpuRngSupportedAlgorithm in the MdePkg in a following patch and to avoid making the MdePkg dependent on another package, move PcdCpuRngSupportedAlgorithm to the MdePkg. As the Pcd is only used for AARCH64, place it in an AARCH64 specific sections. Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Tested-by: Kun Qin <kun.qin@microsoft.com>
* MdePkg: Add deprecated warning to BaseRngLibTimerPierre Gondois2023-09-082-0/+23
| | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4504 To keep the MdePkg self-contained and avoid dependencies on GUIDs defined in other packages, the BaseRngLibTimer was moved to the MdePkg. Add a constructor to warn and request to use the MdeModulePkg implementation. Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Tested-by: Kun Qin <kun.qin@microsoft.com>
* MdeModulePkg: Duplicate BaseRngLibTimerLib to MdeModulePkgPierre Gondois2023-09-0819-18/+262
| | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4504 The BaseRngLibTimerLib allows to generate number based on a timer. This mechanism allows to have a basic non-secure implementation for non-production platforms. To bind and identify Random Number Generators implementations with a GUID, an unsafe GUID should be added. This GUID cannot be added to the MdePkg unless it is also added to a specification. To keep the MdePkg self-contained, copy the BaseRngLibTimerLib to the MdeModulePkg. This will allow to define an unsafe Rng GUID in a later patch in the MdeModulePkg. The MdePkg implementation will be removed later. This allows to give some time to platform owners to switch to the MdeModulePkg implementation. Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Tested-by: Kun Qin <kun.qin@microsoft.com>
* UefiCpuPkg/PiSmmCpuDxe: use MpService2Ppi to wakeup AP in s3Dun Tan2023-09-081-23/+35
| | | | | | | | | | | | Use MpService2Ppi to wakeup AP in s3 boot flow during initializing CPU. If mSmmS3ResumeState->MpService2Ppi is not 0, then BSP will use MpService2Ppi->StartupAllCPUs to do CPU initialization for both BSP and AP instead of only sending InitSipiSipi for AP. Signed-off-by: Dun Tan <dun.tan@intel.com> Cc: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Cc: Rahul Kumar <rahul1.kumar@intel.com>
* UefiCpuPkg/PiSmmCpuDxe: code refinement for CpuS3.cDun Tan2023-09-081-128/+138
| | | | | | | | | | | | | | | This commit is code logic refinement for s3 boot flow in CpuS3.c. It doesn't change any code functionality. This commit implementes InitializeAp and InitializeBsp as a single function since they are doing almost the same thing. Then both BSP and AP will execute the same function InitializeCpuProcedure to do CPU initialization. This can make the code logic easier to understand. Signed-off-by: Dun Tan <dun.tan@intel.com> Cc: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Cc: Rahul Kumar <rahul1.kumar@intel.com>
* UefiCpuPkg/S3Resume2Pei: assert for invalid excution mode comboDun Tan2023-09-081-0/+7
| | | | | | | | | | Add assert for invalid excution mode combination of 64bit PEI + 32bit DXE. Signed-off-by: Dun Tan <dun.tan@intel.com> Cc: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Cc: Rahul Kumar <rahul1.kumar@intel.com>
* UefiCpuPkg/S3Resume2Pei: prepare MpService2Ppi in S3ResumeDun Tan2023-09-082-2/+19
| | | | | | | | | | | Prepare MpService2Ppi in S3Resume when PEI and SMM env run in the same execution mode. Then smm s3 code can use Mp Service to wakeup AP instead of only sending InitSipiSipi. Signed-off-by: Dun Tan <dun.tan@intel.com> Cc: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Cc: Rahul Kumar <rahul1.kumar@intel.com>
* MdeModulePkg: add MpService2Ppi field in SMM_S3_RESUME_STATEDun Tan2023-09-081-1/+2
| | | | | | | | | | | | | Add MpService2Ppi field in SMM_S3_RESUME_STATE of AcpiS3Context.h. It will be used to wakeup AP to do the CPU initialization during smm s3 boot flow in following patches. With this field, we can avoid sending InitSipiSipi to wakeup AP. Signed-off-by: Dun Tan <dun.tan@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn>
* MdePkg/Library/BaseRngLib: Fix include guardMichael Kubacki2023-09-081-0/+1
| | | | | | | | | | | | | The include guard is incomplete and does not define the macro. Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Zhiguang Liu <zhiguang.liu@intel.com> Cc: Rebecca Cran <rebecca@bsdio.com> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Rebecca Cran <rebecca@os.amperecomputing.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* ArmVirtPkg: use PcdTerminalTypeGuidBuffer for VirtioSerial consoleGerd Hoffmann2023-09-071-2/+7
| | | | | | | | | Be consistent with pl011-based serial console setup. Suggested-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg/Include: remove QemuSmramSaveStateMap.hGerd Hoffmann2023-09-073-191/+12
| | | | | | | | | | The qemu/kvm SMM emulation uses the AMD SaveState layout. So, now that we have AMD SaveState support merged we can just use Amd/SmramSaveStateMap.h, QemuSmramSaveStateMap.h is not needed any more. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg/PlatformBootManagerLib: setup virtio-mmio devices.Gerd Hoffmann2023-09-072-0/+32
| | | | | | | | | | Add DetectAndPreparePlatformVirtioDevicePath() helper function to setup virtio-mmio devices. Start with virtio-serial support. This makes virtio console usable with microvm. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg/README: Document Secure BootJoursoir2023-09-071-0/+40
| | | | | | | Add the new section for Secure Boot. Signed-off-by: Alexander Goncharov <chat@joursoir.net> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
* SecurityPkg/SecureBoot: Support RSA4096 and RSA3072Sheng Wei2023-09-078-85/+329
| | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3413 Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Zeyi Chen <zeyi.chen@intel.com> Cc: Fiona Wang <fiona.wang@intel.com> Signed-off-by: Sheng Wei <w.sheng@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* CryptoPkg/BaseCryptLib: add sha384 and sha512 to ImageTimestampVerifySheng Wei2023-09-071-1/+2
| | | | | | | | | | | | | | | | | | | Register and initialize sha384/sha512 digest algorithms for PKCS#7 Handling. REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3413 Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Zeyi Chen <zeyi.chen@intel.com> Cc: Fiona Wang <fiona.wang@intel.com> Cc: Xiaoyu Lu <xiaoyu1.lu@intel.com> Cc: Guomin Jiang <guomin.jiang@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Sheng Wei <w.sheng@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg: Revert "Update build.sh to allow building OVMF then running QEMU"Mike Beaton2023-09-061-4/+11
| | | | | | | | | | | | | | | | | | | | | | | This reverts commit 173a7a7daaad560cd69e1000faca1d2b91774c46 Fixes https://bugzilla.tianocore.org/show_bug.cgi?id=4528 The build.sh qemu option starts the correct qemu executable for the selected architecture (build.sh -a option, or implicit) and uses the correct previously built OVMF image for the selected architecture and build target (build.sh -b option, or implicit). With this revert, the above step will fail if there is no matching previously built OVMF image. This is advantageous over rebuilding each time the build.sh qemu option is used (as in the reverted commit), because it provides a quick way to run a just-built OVMF image in place, while: a) Starting immediately (saving the time required for a rebuild on each usage, if the VM is started multiple times) b) Preserving the NVRAM contents between multiple runs (i.e. until the image is next rebuilt) Signed-off-by: Mike Beaton <mjsbeaton@gmail.com>
* ArmVirtPkg: ArmVirtQemu: Add Graphics and InputOliver Smith-Denny2023-09-061-0/+5
| | | | | | | | | | | | | | | | | | | | | Currently, unlike OVMF, ArmVirtQemu does not display any graphics, only the QEMU monitor. Graphics are helpful to confirm booting into an OS is successful, interacting with the EFI shell while getting separate logging messages, etc. This patch adds the QEMU parameters to launch a graphical window and add a USB keyboard and mouse, which is modeled as a tablet as it tracks better in QEMU than a generic mouse. virtio-gpu-pci is chosen as the graphics device as it is recommended by QEMU for the ARM virtual platform. The graphics and USB input devices will only be added to QEMU when QEMU_HEADLESS == FALSE, so CI builds will not attempt to use the graphics and if a user does not want graphics, they can add QEMU_HEADLESS=TRUE to the build cmdline. Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg: Fix Hii form name mismatch with EFI variableYin Wang2023-09-061-1/+1
| | | | | | | | | | | | | | | | The Hii form is named "MainFormState" while the EFI variable is named "PlatformConfig". This discrepancy in names causes the following SCT cases to fail on RiscVVirtQemu: ExtractConfigConformance ExtractConfigFunction ExtractConfig_Func Previous commit 16acacf addressed two of these issues, and this patch fixes the remaining one. Signed-off-by: Yin Wang <yin.wang@intel.com> Reviewed-by: Dandan Bi <dandan.bi@intel.com>
* OvmfPkg/AmdSev: fix BdsPlatform.c assertion failure during bootRoth, Michael via groups.io2023-09-052-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | Booting an SEV guest with AmdSev OVMF package currently triggers the following assertion with QEMU: InstallQemuFwCfgTables: installed 7 tables PcRtc: Write 0x20 to CMOS location 0x32 [Variable]END_OF_DXE is signaled Initialize variable error flag (FF) ASSERT_EFI_ERROR (Status = Not Found) ASSERT [BdsDxe] /home/VT_BUILD/ovmf/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c(1711): !(((INTN)(RETURN_STATUS)(Status)) < 0) This seems to be due to commit 81dc0d8b4c, which switched to using PlatformBootManagerLib instead of PlatformBootManagerLibGrub. That pulls in a dependency on gEfiS3SaveStateProtocolGuid provider being available (which is asserted for in BdsPlatform.c:PlatformBootManagerBeforeConsole()/SaveS3BootScript()), but the libraries that provide it aren't currently included in the build. Add them similarly to what's done for OvmfPkg. Fixes: 81dc0d8b4c ("OvmfPkg/AmdSev: stop using PlatformBootManagerLibGrub") Signed-off-by: Michael Roth <michael.roth@amd.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
* Revert "ArmPkg: add ArmCpuInfo EFI application"Marcin Juszkiewicz2023-09-053-2462/+0
| | | | | | | | | I am moving this command outside of EDK2. This reverts commit 2c2cb235289642775a7c4e6eaeffa6d3828d279c. Signed-off-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org> Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
* OvmfPkg/AmdSev: Disable PcdFirstTimeWakeUpAPsBySipiMichael Roth2023-09-051-0/+8
| | | | | | | | | | | | | | | | | PcdFirstTimeWakeUpAPsBySipi was recently introduced to indicate when the full INIT-SIPI-SIPI sequence can be skipped for AP bringup. It is true by default, but needs to be disabled for QEMU/OVMF where early INIT is not simulated. Commit 1d76560146 ("OvmfPkg: Disable PcdFirstTimeWakeUpAPsBySipi.") added changes to disable it by default for OvmfPkg, but a similar change was not made for the AmdSev package. This breaks booting of SEV and SNP guests. Fix this defaulting PcdFirstTimeWakeUpAPsBySipi to false for AmdSev package, as was previously done for OvmfPkg variants. Fixes: eaffa1d7ff ("UefiCpuPkg:Wake up APs after power-up or RESET through SIPI.") Signed-off-by: Michael Roth <michael.roth@amd.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg/IoMmuDxe: don't rely on TPLs to manage concurrencyArd Biesheuvel2023-09-022-41/+60
| | | | | | | | | | | | | | | | | Instead of relying on raising the TPL to protect the critical sections that manipulate the global bitmask that keeps track of bounce buffer allocations, use compare-and-exchange to manage the global variable, and tweak the logic to line up with that. Given that IoMmuDxe implements a singleton protocol that is shared between multiple drivers, and considering the elaborate and confusing requirements in the UEFP spec regarding TPL levels at which protocol methods may be invoked, not relying on TPL levels at all is a more robust approach in this case. Link: https://bugzilla.redhat.com/show_bug.cgi?id=2211060 Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Pedro Falcato <pedro.falcato@gmail.com>
* MdeModulePkg: Fix memory leak in LocateHandleBuffer()Nate DeSimone2023-08-311-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4543 REF: https://uefi.org/specs/UEFI/2.10/07_Services_Boot_Services.html#efi-boot-services-locatehandlebuffer CoreLocateHandleBuffer() can in certain cases, return an error and not free an allocated buffer. This scenario occurs if the first call to InternalCoreLocateHandle() returns success and the second call returns an error. On a successful return, LocateHandleBuffer() passes ownership of the buffer to the caller. However, the UEFI specification is not explicit about what the expected ownership of this buffer is in the case of an error. However, it is heavily implied by the code example given in section 7.3.15 of v2.10 of the UEFI specificaton that if LocateHandleBuffer() returns a non-successful status code then the ownership of the buffer does NOT transfer to the caller. This code example explicitly refrains from calling FreePool() if LocateHandleBuffer() returns an error. From a practical standpoint, it is logical to assume that a non-successful status code indicates that no buffer of handles was ever allocated. Indeed, in most error cases, LocateHandleBuffer() does not go far enough to get to the point where a buffer is allocated. Therefore, all existing users of this API must already be coded to support the case of a non-successful status code resulting in an invalid handle buffer being returned. Therefore, this change will not cause any backwards compatibility issues with existing code. In conclusion, this boils down to a fix for a memory leak that also brings the behavior of our LocateHandleBuffer() implementation into alignment with the original intentions of the UEFI specification authors. Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Dandan Bi <dandan.bi@intel.com> Signed-off-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
* ShellPkg: Add ProcessorUpgradeSocket definitions from SMBIOS 3.7.0Eduardo Cuevas Farfan2023-08-311-1/+33
| | | | | | | | | | | | | | | | This patch adds below definitions from SMBIOS 3.7.0 into QueryTable.c - ProcessorUpgradeSocketAM5 - ProcessorUpgradeSocketSP5 - ProcessorUpgradeSocketSP6 - ProcessorUpgradeSocketBGA883 - ProcessorUpgradeSocketBGA1190 - ProcessorUpgradeSocketBGA4129 - ProcessorUpgradeSocketLGA4710 - ProcessorUpgradeSocketLGA7529 Signed-off-by: Eduardo Cuevas Farfan <eduardo.cuevas.farfan@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
* MdePkg: Add ProcessorUpgradeSocket definitions from SMBIOS 3.7.0Eduardo Cuevas Farfan2023-08-311-3/+11
| | | | | | | | | | | | | | | | This patch adds below definitions from SMBIOS 3.7.0 into Smbios.h - ProcessorUpgradeSocketAM5 - ProcessorUpgradeSocketSP5 - ProcessorUpgradeSocketSP6 - ProcessorUpgradeSocketBGA883 - ProcessorUpgradeSocketBGA1190 - ProcessorUpgradeSocketBGA4129 - ProcessorUpgradeSocketLGA4710 - ProcessorUpgradeSocketLGA7529 Signed-off-by: Eduardo Cuevas Farfan <eduardo.cuevas.farfan@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
generated by cgit (git 2.34.1) at 2025-02-23 05:19:44 +0000