summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* MdeModulePkg/Bus/Pci/NvmExpressPei: Fix DEADCODE Coverity issueRanbir Singh2023-09-201-4/+0
| | | | | | | | | | | | | | | The code can reach line 65 only through the else path above at line 53. The else path already has the same NULL check at line 55 and hence the duplicate code lines are totally redundant which can be deleted. REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4220 Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Ray Ni <ray.ni@intel.com> Co-authored-by: Veeresh Sangolli <veeresh.sangolli@dellteam.com> Signed-off-by: Ranbir Singh <Ranbir.Singh3@Dell.com> Signed-off-by: Ranbir Singh <rsingh@ventanamicro.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
* MdeModulePkg/Bus/Ata/AtaBusDxe: Fix SIGN_EXTENSION Coverity issueRanbir Singh2023-09-201-1/+1
| | | | | | | | | | | | | | | Line number 365 does contain a typecast with UINT32, but it is after all the operations (16-bit left shift followed by OR'ing) are over. To avoid any SIGN_EXTENSION, typecast the intermediate result after 16-bit left shift operation immediately with UINT32. REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4209 Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Ray Ni <ray.ni@intel.com> Signed-off-by: Ranbir Singh <Ranbir.Singh3@Dell.com> Signed-off-by: Ranbir Singh <rsingh@ventanamicro.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
* ArmVirtPkg: handle virtual EL2 timer in DTLeif Lindholm2023-09-197-3/+14
| | | | | | | | | | | | | | | | | | | FEAT_VHE, introduced in ARMv8.1, adds a virtual EL2 timer. However, this library verifies that exactly 3 or 4 12-byte timer interrupts are provided in input DT, ASSERTing when the new timer is added. Change the assert to >= 36. Extend the current logic, also initializing PcdArmArchTimerHypVirtIntrNum if 5 interrupts are provided. Signed-off-by: Leif Lindholm <quic_llindhol@quicinc.com> Reported-by: Peter Maydell <peter.maydell@linaro.org> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Sami Mujawar <sami.mujawar@arm.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Tested-by: Peter Maydell <peter.maydell@linaro.org>
* ArmPkg: add EL2 virtual timer interrupt PcdLeif Lindholm2023-09-191-0/+1
| | | | | | | | | | | | | | PcdArmArchTimerHypVirtIntrNum, defaults to 28 as defined in Arm's Base System Architecture (current version DEN0094C 1.0C). Relevant for systems implementing FEAT_VHE, added in ARMv8.1. Signed-off-by: Leif Lindholm <quic_llindhol@quicinc.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Sami Mujawar <sami.mujawar@arm.com> Signed-off-by: Leif Lindholm <quic_llindhol@quicinc.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
* RedfishPkg/RedfishRestExDxe: return HTTP status code to caller.Nickle Wang2023-09-192-14/+16
| | | | | | | | | | | | | | | | Return unsupported HTTP status code to caller so caller can handle HTTP error status code. Current implementation only return EFI error to caller. Without knowing the HTTP status code, caller has trouble to handle HTTP request failure. 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> Cc: Mike Maslenkin <mike.maslenkin@gmail.com> Reviewed-by: Igor Kulchytskyy <igork@ami.com> Reviewed-by: Abner Chang <abner.chang@amd.com> Acked-by: Mike Maslenkin <mike.maslenkin@gmail.com>
* BaseTools/Plugin: Add DebugMacroCheckMichael Kubacki2023-09-198-0/+2256
| | | | | | | | | | | | | | | | | | | | | | | | | | Adds a plugin that finds debug macro formatting issues. These errors often creep into debug prints in error conditions not frequently executed and make debug more difficult when they are encountered. The code can be as a standalone script which is useful to find problems in a large codebase that has not been checked before or as a build plugin that notifies a developer of an error right away. The script was already used to find numerous issues in edk2 in the past so there's not many code fixes in this change. More details are available in the readme file: .pytool\Plugin\DebugMacroCheck\Readme.md Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Bob Feng <bob.c.feng@intel.com> Cc: Yuwei Chen <yuwei.chen@intel.com> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
* OvmfPkg/PlatformCI: Disable DebugMacroCheckMichael Kubacki2023-09-191-0/+1
| | | | | | | | | | | | Disables the DebugMacroCheck CI plugin to reduce CI checks performed in the package. 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> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
* DynamicTablesPkg.ci.yaml: Add debug macro exceptionMichael Kubacki2023-09-191-0/+8
| | | | | | | | | | | | Adds a CI YAML entry to acknowledge a case where custom strings contain print specifiers for a single debug macro. Cc: Sami Mujawar <Sami.Mujawar@arm.com> Cc: Alexei Fedorov <Alexei.Fedorov@arm.com> Cc: Pierre Gondois <pierre.gondois@arm.com> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Acked-by: Sami Mujawar <sami.mujawar@arm.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
* ArmVirtPkg.ci.yaml: Add debug macro exceptionMichael Kubacki2023-09-191-0/+8
| | | | | | | | | | | | | Adds a CI YAML entry to acknowledge a case where a macro is expanded that contains a print specifier. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Leif Lindholm <quic_llindhol@quicinc.com> Cc: Sami Mujawar <sami.mujawar@arm.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
* SecurityPkg.ci.yaml: Add debug macro exceptionMichael Kubacki2023-09-191-0/+9
| | | | | | | | | | Adds a CI YAML entry to acknowledge a case where a single argument is matched to a format specifier with a ternary operator. Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
* pip-requirements.txt: Add regexMichael Kubacki2023-09-191-1/+1
| | | | | | | | | | | | | | regex is a popular PIP module for regular expression support. https://pypi.org/project/regex/ This change adds regex for the upcoming DebugMacroCheck plugin. Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
* RedfishPkg/PlatformHostInterfaceBmcUsbNicLib: Fix DEBUG macro argsMichael Kubacki2023-09-191-4/+4
| | | | | | | | | | | Some macros added have a mismatched number of print specifiers to arguments. Cc: Abner Chang <abner.chang@amd.com> Cc: Nickle Wang <nicklew@nvidia.com> Cc: Igor Kulchytskyy <igork@ami.com> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Abner Chang <abner.chang@amd.com>
* MdeModulePkg: Memory Bin Range Update Accounts for Guard PageTaylor Beebe2023-09-181-1/+1
| | | | | | | | | | | | | | | | | | | | When finding a free page range for allocation, if the found range starts below the tracked memory bin address range, the lowest memory bin address is updated which will not include the guard page if present. When CoreConvertPagesWithGuard() is called on the range being allocated, the memory range is adjusted to include guard pages which can push it out of the memory bin address range and cause the memory type statistics to be unaltered. This patch updates the lowest memory bin address range to account for the guard page if NeedGuard is TRUE so the memory type statistics are updated correctly. Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Dandan Bi <dandan.bi@intel.com> Signed-off-by: Taylor Beebe <t@taylorbeebe.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* UefiCpuPkg/ResetVector: Remove AP waking vector from ResetVectorZhiguang Liu2023-09-182-19/+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: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
* OvmfPkg: Remove applicationProcessorEntryPointZhiguang Liu2023-09-182-25/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* UefiCpuPkg/SecCore: Remove AP waking Vector logic in SecCoreZhiguang Liu2023-09-181-33/+3
| | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4494 There are two part of AP waking Vector logic in SecCore. The first one working with GenFv to find a free 4K aligned space, use the 4K aligned address as AP waking Vector and jump to 4G-30h, and finally jump to ApStartup.. The second one hard code uses 4G-1000h as AP waking Vector and jump to ApStartup. Both usages are no longer used. Remove them. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
* BaseTools: Remove logic to create AP waking vector in GenFvZhiguang Liu2023-09-181-199/+0
| | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4494 Today for SEC core(not VTF-0), GenFv finds free 4K aligned space in FV for AP waking vector and JMP to 4G-30h in the waking vector. There is no usage of this today. Remove the logic to avoid confusing and save spaces in reset vector. Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Bob Feng <bob.c.feng@intel.com> Cc: Yuwei Chen <yuwei.chen@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
* OvmfPkg/RiscVVirt/README: document direct kernel bootLaszlo Ersek2023-09-141-1/+32
| | | | | | | | | | | | | | | | | | | Direct (fw_cfg) kernel boot works on the RiscVVirt firmware platform too; I've tested it after extracting the kernel, initrd, and kernel command line from "openSUSE-Tumbleweed-RISC-V-E20-efi.riscv64.raw". Document this type of boot, because at least historically, fw_cfg kernel boot was implemented differently between OVMF and ArmVirtQemu. Thanks: Drew, Sunil. Cc: Andrei Warkentin <andrei.warkentin@intel.com> Cc: Andrew Jones <ajones@ventanamicro.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: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
* OvmfPkg/RiscVVirt/README: explain the "acpi=off" machine propertyLaszlo Ersek2023-09-141-0/+5
| | | | | | | | | | | | | | | | "acpi=off" is arguably unusual with UEFI guest OSes; add a note to explain it. Original explanation by Drew Jones. Cc: Andrei Warkentin <andrei.warkentin@intel.com> Cc: Andrew Jones <ajones@ventanamicro.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: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
* OvmfPkg/RiscVVirt/README: explain that "-bios" is only useful with TCGLaszlo Ersek2023-09-141-0/+5
| | | | | | | | | | | | | | | | | Riscv64 KVM services SBI calls internally, so OpenSBI is not used in such setups. Restrict the "-bios" flag accordingly. Thanks: Andrei, Drew. Cc: Andrei Warkentin <andrei.warkentin@intel.com> Cc: Andrew Jones <ajones@ventanamicro.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> [lersek@redhat.com: '-bios' is rejected with KVM accel (Drew)] Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
* Pyrite support - Secure erase is only available if encryption is supported.Linus Liu2023-09-131-1/+5
| | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=3004 Cc: Qi Zhang <qi1.zhang@intel.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tina Chen <tina.chen@intel.com> Cc: Xiao X Chen <xiao.x.chen@intel.com> Signed-off-by: Linus Liu <linus.liu@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-09 05:17:35 +0000