REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4438
The main dispatch loop in PeiDispatcher() goes through each FV and
calls DiscoverPeimsAndOrderWithApriori() to search Apriori file to
reorder all PEIMs then do the PEIM dispatched.
DiscoverPeimsAndOrderWithApriori() calculates Apriori file count for
every FV once and set Private->AprioriCount, but Private->AprioriCount
doesn't be set to 0 before dispatch loop walking through the next FV.
It causes the peim which sort on less than Private->AprioriCount and
depex is not satisfied would be dispatched when dispatch loop go through
to a scaned FV, even the peim is not set in APRIORI file.
Cc: Leon Chen <leon.chen@insyde.com>
Cc: Tim Lewis <tim.lewis@insyde.com>
Reported-by: Esther Lee <esther.lee@insyde.com>
Signed-off-by: Wendy Liao <wendy.liao@insyde.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
The helper that updates live page table entries writes a zero entry,
invalidates the covered address range from the TLBs, and finally writes
the actual entry. This ensures that no TLB conflicts can occur.
Writing the final entry needs to complete before any translations can be
performed, as otherwise, the zero entry, which describes an invalid
translation, may be observed by the page table walker, resulting in a
translation fault. For this reason, the final write is followed by a DSB
barrier instruction.
However, this barrier will not stall the pipeline, and instruction
fetches may still hit this invalid translation, as has been observed and
reported by Oliver. To ensure that the new translation is fully active
before returning from this helper, we have to insert an ISB barrier as
well.
Reported-by: Oliver Steffen <osteffen@redhat.com>
Tested-by: Oliver Steffen <osteffen@redhat.com>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Acked-by: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
If the SerialPortLib had any initialization needed, this
would be skipped in the RiscVVirt Sec. Follow the example
seen elsewhere (ArmVirtPkg PrePi).
Seen with BaseSerialPortLibRiscVSbiLibRam not using DBCN in Sec,
yet using DBCN elsewhere.
Cc: Daniel Schaefer <git@danielschaefer.me>
Signed-off-by: Andrei Warkentin <andrei.warkentin@intel.com>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
These are implementations of SerialPortLib using SBI console services.
- BaseSerialPortLibRiscVSbiLib is appropriate for SEC/PEI (XIP)
environments
- BaseSerialPortLibRiscVSbiLibRam is appropriate for PrePI/DXE
environments
Tested with:
- Qemu RiscVVirt (non-DBCN case, backed by UART)
- TinyEMU + RiscVVirt (non-DBCN case, HTIF)
- TinyEMU + RiscVVirt (DBCN case, HTIF)
Cc: Daniel Schaefer <git@danielschaefer.me>
Cc: Sunil V L <sunilvl@ventanamicro.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Signed-off-by: Andrei Warkentin <andrei.warkentin@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
After moving BDS driver to a new FV for universal UEFI payload,
the shell boot option path is not correct since it used the BDS
FV instead of DXE FV in its device path.
This patch would find the correct FV by reading shell file.
It also removed PcdShellFile by using gUefiShellFileGuid.
Signed-off-by: Guo Dong <guo.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Sean Rhodes <sean@starlabs.systems>
Cc: James Lu <james.lu@intel.com>
Cc: Gua Guo <gua.guo@intel.com>
Reviewed-by: James Lu <james.lu@intel.com>
Reviewed-by: Gua Guo <gua.guo@intel.com>
Reviewed-by: Mike Maslenkin <mike.maslenkin@gmail.com>
The warnings Clang emits when enabling -Wunneeded-internal-declaration
(which is part of -Wall) are generating false positives for variables
whose size gets taken but are not referenced beyond yet.
This may happen legitimately in debug code, so let's disable this
warning for Clang, rather than tiptoe around it in the code.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
When using CLANGDWARF to build for the ARM architecture, objcopy is
references via the wrong environment variable, resulting in the wrong
llvm-objcopy to be used (if one exists), or the build to fail (if
CLANGDWARF_BIN points to the only available instance)
So use CLANGDWARF_BIN instead, which was what was intended.
Fixes: ecbc394365 ("BaseTools: Set CLANGDWARF RC path ...")
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3805
Replace hardcoded SMBIOS Anchor string and size with defines.
Fix buffer overflow as described below.
Smbios64BitPrintEPSInfo () is coded like:
UINT8 Anchor[5];
MemToString (Anchor, SmbiosTable->AnchorString, 5);
But the definition of MemToString()
Copy Length of Src buffer to Dest buffer,
add a NULL termination to Dest buffer.
So Anchor needs to be +1 the size of the SMBIOS Anchor string `_SM3_`.
Changes from v1 to v2:
- Replace doxygen style inline comments
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Cc: Andrew Fish <afish@apple.com>
Signed-off-by: Giri Mudusuru <girim@apple.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Windows command prompt have 8191 characters limitation,
enhance it to make command too long can be resloved.
Provide an example, if have too many cov files, it causes to run single
command over the 8191 characters limitation.
> OpenCppCoverage
> --export_type binary:coverage.cov
> --working_dir={workspace}Build
> --input_coverage=AAA.cov
> ...
> --input_coverage=NNN.cov
The solution is passing many coverage files in single command line to
breaking it up into many command lines with one coverage file per
command line in order to prevent single line is over to 8191 characters.
- Command Line 1
> OpenCppCoverage
> --export_type binary:coverage.cov
> --working_dir={workspace}Build
> --input_coverage=AAA.cov
> --input_coverage=coverage.cov
...
- Command Line N
> OpenCppCoverage
> --export_type. binary:coverage.cov
> --working_dir={workspace}Build
> --input_coverage=NNN.cov
> --input_coverage=coverage.cov
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Michael Kubacki <mikuback@linux.microsoft.com>
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: Gua Guo <gua.guo@intel.com>
Reviewed-by: Michael Kubacki <mikuback@linux.microsoft.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
On Windows, executables have a '.exe' suffix which needs to be added for
them to be found in a path.
Also, files need to be explicitly opened as binary.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
The BASETOOLS_PYTHON_SOURCE environment variable is only used temporarily to
set PYTHONPATH. Since it doesn't help improve clarity, remove it.
While here, make sure we set PYTHONPATH when we're using Pip BaseTools
so that build etc. can be found.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
This reverts commit 11f62f4cc0.
While GCC uses objcopy for the OBJCOPY command, it's not needed for the
CLANGDWARF toolchain and can be left as echo.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Ard BIesheuvel <ardb@kernel.org>
Use PlatformBootManagerLib with PcdBootRestrictToFirmware
set to TRUE instead.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
In case PcdBootRestrictToFirmware is set, disable loading EFI variables
from NvVars file.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Add new PCD PcdBootRestrictToFirmware. When set to TRUE restrict
boot options to EFI applications embedded into the firmware image.
Behavior should be identical to the PlatformBootManagerLibGrub
library variant.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Remove bashisms from edksetup.sh and BaseTools/BuildEnv. This allows any
POSIX shell to use those scripts, removing the dependency on bash.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
The build rule for Hii-Binary-Package.UEFI_HII should be the same as for
GCC, using $(RC) to embed the HII resource into the binary. Since the
build rule defaults to GCC, just remove CLANGGCC from the section.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Tested-by: Michael D Kinney <michael.d.kinney@intel.com>
The llvm-rc tool is for Windows PE resources. Since the CLANGDWARF
toolchain creates ELF binaries, update the RC path to be llvm-objcopy.
This follows the GCC toolchain which uses objcopy for the RC path.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Tested-by: Michael D Kinney <michael.d.kinney@intel.com>
There's only a single rule in build_rule.template for CLANGGCC, and it's
incorrect. We should instead just use the rules for GCC, so remove the
BUILDRULEFAMILY line for the CLANGDWARF toolchain definition.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Tested-by: Michael D Kinney <michael.d.kinney@intel.com>
Since CLANG35 and CLANG38 toolchains have been deleted from
tools_def.template, delete the build flags for them from CryptoPkg.
Since CLANGDWARF has replaced CLANG38, add build flags for it to the
CryptoPkg .inf files.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
At TPL_HIGH_LEVEL, CPU interrupts are disabled (as per the UEFI
specification) and so we should never encounter a situation in which
an interrupt occurs at TPL_HIGH_LEVEL. The specification also
restricts usage of TPL_HIGH_LEVEL to the firmware itself.
However, nothing actually prevents a UEFI application from calling
gBS->RaiseTPL(TPL_HIGH_LEVEL) and then violating the invariant by
enabling interrupts via the STI or equivalent instruction. Some
versions of the Microsoft Windows bootloader are known to do this.
NestedInterruptTplLib maintains the invariant that interrupts are
disabled at TPL_HIGH_LEVEL (even when performing the dark art of
deliberately manipulating the stack so that IRET will return with
interrupts still disabled), but does not itself rely on external code
maintaining this invariant.
Relax the assertion that the interrupted TPL is below TPL_HIGH_LEVEL
to an error message, to allow UEFI applications such as these versions
of the Microsoft Windows bootloader to continue to function.
Debugged-by: Gerd Hoffmann <kraxel@redhat.com>
Debugged-by: Laszlo Ersek <lersek@redhat.com>
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=2189136
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
NestedInterruptTplLib relies on CPU interrupts being disabled to
guarantee exclusive (and hence atomic) access to the shared state in
IsrState. Nothing in the calling interrupt handler should have
re-enabled interrupts before calling NestedInterruptRestoreTPL(), and
the loop in NestedInterruptRestoreTPL() itself maintains the invariant
that interrupts are disabled at the start of each iteration.
Add assertions to clarify this invariant, and expand the comments
around the calls to RestoreTPL() and DisableInterrupts() to clarify
the expectations around enabling and disabling interrupts.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Update toolsetup.bat and Tests/PythonTest.py to check if we're running a
version of Python that's compatible with BaseTools and the Pip
BaseTools.
BaseTools uses syntax from Python 3.6 or newer, so set that as the minimum
version EDK2 requires.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
If toolsetup.bat fails (i.e. exits with a non-zero %ERRORLEVEL%), don't
try and carry on but just quit.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
threading.currentThread is a deprecated alias for
threading.current_thread, and causes a warning to be displayed when it's
called. Update NmakeSubdirs.py to use the latter method instead.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Since Python3 is now required, we can remove the checks for PYTHON3_ENABLE
and PYTHON3 and simplify the code in toolsetup.bat. Also, remove the
leftover from when we supported freezing Python code.
While here, fix a couple of typos and improve error messages.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
When a MAC address matching interface is found, a RestEx child will be
created to provide the Redfish communication on that interface.
Currently, It will try to locate all RestEx binding services and choose
the first satisfied instance without taking care about current selected
interface. This might raise an issue on the system with multiple network
devices that the RestEx child was installed on wrong interface.
Signed-off-by: Minh Nguyen <minhnguyen1@os.amperecomputing.com>
Cc: Abner Chang <abner.chang@amd.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Cc: Nick Ramirez <nramirez@nvidia.com>
Reviewed-by: Abner Chang <Abner.Chang@amd.com>
Clang 3.8 is a very old release and is no longer relevant. Delete the
CLANG38 toolchain from tools_def.template.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Tested-by: Michael D Kinney <michael.d.kinney@intel.com>
Clang 3.5 is a very old release and is no longer relevant. Remove the
CLANG35 toolchain from tools_def.template.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Tested-by: Michael D Kinney <michael.d.kinney@intel.com>
As with the IA32 and X64 CLANGDWARF toolchain definitions, use ld.lld
for ARM and AARCH64.
Add -Wl,--no-pie,--no-relax to the command line to fix linking when
using lld.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Tested-by: Michael D Kinney <michael.d.kinney@intel.com>
Add a 'GCC' toolchain that's a copy of the existing GCC5 definition.
Add a 'GCCNOLTO' toolchain that's a copy of the existing GCC49
toolchain.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Tested-by: Michael D Kinney <michael.d.kinney@intel.com>
Update the Visual Studio toolchain descriptions in
tools_def.txt.template:
- The WinDDK is no longer needed.
- Update 3 is required for VS 2015.
- VS 2005 has been removed.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Tested-by: Michael D Kinney <michael.d.kinney@intel.com>
The edk2-stable202302 release was the last to support building
EFI Byte Code drivers. Since the Intel EFI Byte Code Compiler is no
longer available, a decision has been made to remove support for EBC
from edk2.
Remove the definitions for Intel's EBC compiler from
Conf/tools_def.template.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Tested-by: Michael D Kinney <michael.d.kinney@intel.com>
With recent changes, Visual Studio versions older than VS2015 are
unable to build EDK2 code.
To avoid confusion, remove VS2008, 2010, 2012 and 2013 toolchain
definitions from Conf/tools_def.template, leaving only versions that can
be used to successfully build firmware.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Tested-by: Michael D Kinney <michael.d.kinney@intel.com>
Older versions of GenFw put the wrong value in the debug directory size
field in the PE/COFF header: instead of putting the combined size of all
the entries, it puts the size of the only entry it creates, but adds the
size of the NB10 payload that the entry points to. This confuses the
loader now that we started using additional debug directory entries to
describe DLL characteristics.
GenFw was fixed in commit 60e85a39fe, but the binaries that were
generated with it still need to be supported.
So let's detect this condition, and check whether the size of the debug
directory is consistent with the NB10 payload: if we should expect
additional directory entries where we observe the NB10 payload, the size
field is clearly wrong, and we can break from the loop.
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4425
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Tested-by: Liming Gao <gaoliming@byosoft.com.cn>
Acked-by: Michael Kubacki <michael.kubacki@microsoft.com>
Add a driver for the virtio serial device.
The virtio serial device also known as virtio console device because
initially it had only support for a single tty, intended to be used as
console. Support for multiple streams and named data ports has been
added later on.
The driver supports tty ports only, they are registered as SerialIo
UART in the system.
Named ports are detected and logged, but not exposed as devices. They
are usually used by guest agents to communicate with the host. It's not
clear whenever it makes sense for the firmware to run such agents and if
so which efi protocol could be to expose the ports. So leaving that for
another day.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Add header files with structs and defines for the virtio serial device.
The virtio serial device also known as virtio console device because
initially it had only support for a single tty, intended to be used as
console. Support for multiple streams and named data ports has been
added later on.
https://docs.oasis-open.org/virtio/virtio/v1.2/cs01/virtio-v1.2-cs01.html#x1-2900003
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
ArmVirtXen.dsc initializes
gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString with with the
value of the variable "FIRMWARE_VER".
Move that functionality to ArmVirt.dsc.inc to make it available to all
ArmVirt packages, and make it conditional: only set the PCD string if
FIRMWARE_VER is actually defined.
This allows specifying the firmware version string on the build command
line with -D FIRMARE_VER=...
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Initialize gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString with
with the value of the variable "FIRMWARE_VER", if is is defined. Applies
to all flavors of OvmfPkg.
This behavior is already implemented in ArmVirtXen.dsc. It allows
specifying the firmware version string on the build command line with
-D FIRMARE_VER=...
Introduce a common include file to be used in the .dsc files for the
different OVMF flavors, and add the changes there. (ArmVirtPkg already
has such a file).
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
The UEFI Shell is a non-active boot option, at the opposite of UiApp.
If no valid boot option is found, UiApp is selected. UiApp requires a
human interaction. When installing a new EDKII image in CIs or when
scripting is required, this is problematic.
If no valid boot option is discovered, add a path to directly go to
the UEFI Shell where the startup.nsh script is automatically executed.
The UEFI Shell is launched after connecting possible devices, but
before the reset that is meant to automatically make them visible.
The new PcdUefiShellDefaultBootEnable must be set to TRUE to enable
this behaviour. The Pcd is set to false by default.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Tested-by: Patrik Berglund <patrik.berglund@arm.com>
The code blindly assumes a TIS interface is present in case both CRB and
FIFO checks fail. Check the InterfaceType for TIS instead and only
return PtpInterfaceTis in case it matches, PtpInterfaceMax otherwise.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
The code blindly assumes a TIS interface is present in case both CRB and
FIFO checks fail. Check the InterfaceType for TIS instead and only
return Tpm2PtpInterfaceTis in case it matches, Tpm2PtpInterfaceMax
otherwise.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
This is the Implementation of EDKII_REDFISH_PLATFORM_CONFIG_PROTOCOL,
which is the EDKII Redfish Platform Config driver instance that accesses
EDK2 HII configuration format and storage.
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: Abner Chang <abner.chang@amd.com>
Reviewed-by: Igor Kulchytskyy <igork @ami.com>
EDKII Redfish Platform Config Protocol defines the protocol
interfaces that abstracts the platform configuration format
and storage from EDK2 Redfish Feature driver. This protocol
provides the interfaces to get and set platform configuration
with the format and configuration storage agnostic to the
Redfish feature driver.
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: Abner Chang <abner.chang@amd.com>
Reviewed-by: Igor Kulchytskyy <igork @ami.com>
Arm CI build error:
- ArmPkg/Library/CompilerIntrinsicsLib/memset.c:39:1: warning: type of
‘memset’ does not match original declaration [-Wlto-type-mismatch]
MdeModulePkg/Universal/RegularExpressionDxe/OnigurumaUefiPort.c:123:1:
note: type ‘char’ should match type ‘int’
- multiple definition of `memcpy'; OnigurumaUefiPort.obj (symbol from
plugin):(.text+0x0): first defined here
Fix:
- Update memset() implementation to match memset() definition in
ArmPkg/Library/CompilerIntrinsicsLib.
- memcpy() is supported by ArmPkg/Library/CompilerIntrinsicsLib. Exclude
it in OnigurumaUefiPort.c.
Signed-off-by: Nickle Wang <nicklew@nvidia.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Nick Ramirez <nramirez@nvidia.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Add the AUTH_SIG_NOT_FOUND Action to the Image Execution Info Table
when the Image is signed but signature is not allowed by DB and the
hash of image is not found in DB/DBX.
This is documented in the UEFI spec 2.10, table 32.5.
This issue is found by the SIE SCT with the error message as follows:
SecureBoot - TestImage1.bin in Image Execution Info Table with
SIG_NOT_FOUND. --FAILURE
B3A670AA-0FBA-48CA-9D01-0EE9700965A9
SctPkg/TestCase/UEFI/EFI/RuntimeServices/SecureBoot/BlackBoxTest/
ImageLoadingBBTest.c:1079:Status Success
Signed-off-by: Nhi Pham <nhi@os.amperecomputing.com>
Reviewed-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Azure should install code coverage tool (lcov), it didn't
exist on Fedora and Ubuntu by default.
Update docker setting, pick below solution between 47addc9 and 3b3eb8f
3b3eb8f Fixes and improvements to dev containers (#69)
54e5bd1 Enable GTK on Fedora QEMU (#63)
f1c7a20 Fedora: install code coverage tools for GCC (#62)
2ce82af Ubuntu-22: Add initial Ubuntu-22 image (#61)
14d2aba Add Fedora 37 image with gcc12 (#60)
5b8a008 Add dotnet runtime to fedora build (#57)
f5c874a Fix platform build file name for EDK2 change (#58)
48540ad Ubuntu-20: Fix dev image entrypoint (#55)
98e849d Fedora-35: Add Powershell to build image (#52)
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Michael Kubacki <mikuback@linux.microsoft.com>
Cc: Oliver Steffen <osteffen@redhat.com>
Cc: Chris Fernald <chfernal@microsoft.com>
Signed-off-by: Gua Guo <gua.guo@intel.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Michael Kubacki <mikuback@linux.microsoft.com>
Reviewed-by: Chris Fernald <chfernal@microsoft.com>
Currently OVMF tries to rely on the base size advertised via the CPUID
table entries corresponding to leaf 0xD, sub-leafs 0x0/0x1. This will
generally work for KVM guests, but might not for other SEV-SNP
hypervisor implementations. Make the handling more robust by simply
using the base area size documented by the APM.
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Jiewen Yao <jiewen.yao@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Michael Roth <michael.roth@amd.com>
CPUID leaf 0xD sub-leafs 0x0 and 0x1 contain cumulative sizes for the
enabled XSave areas. Those sizes are calculated by tallying up all the
other sub-leafs that contain per-area size information for XSave areas
that are currently enabled in XCr0/XSS. The current check has the logic
inverted. Fix that.
This doesn't seem to cause problems currently, but could in the future
if OVMF made more extensive use of XSave areas. It was noticed while
implementing SNP-related tests for KVM Unit Tests, which re-uses the
OVMF #VC handler in some cases.
Reported-by: Pavan Kumar Paluri <papaluri@amd.com>
Cc: Pavan Kumar Paluri <papaluri@amd.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Jiewen Yao <jiewen.yao@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Michael Roth <michael.roth@amd.com>
The Confidential Computing blob defined here is intended to match the
definition defined by linux guest kernel. Previously, both definitions
relied on natural alignment, but that relies on both OVMF and kernel
being compiled as 64-bit. While there aren't currently any plans to
enable SNP support for 32-bit compilations, the kernel definition has
since been updated to use explicit padding/reserved fields to avoid
this dependency. Update OVMF to match that definition.
While at it, also fix up the Reserved fields to match the numbering
used in the kernel.
No functional changes (for currently-supported environments, at least).
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Jiewen Yao <jiewen.yao@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Michael Roth <michael.roth@amd.com>
The SEV-SNP Confidential Computing blob contains metadata that should
remain accessible for the life of the guest. Allocate it as
EfiACPIReclaimMemory to ensure the memory isn't overwritten by the guest
operating system later.
Reported-by: Dov Murik <dovmurik@linux.ibm.com>
Suggested-by: Dov Murik <dovmurik@linux.ibm.com>
Reviewed-by: Dov Murik <dovmurik@linux.ibm.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Michael Roth <michael.roth@amd.com>
gRedfishDiscoveredToken may be allocated several times,
if multiple NIC installed on the system.
To avoid this issue Discover Token related global variables
replaced with the local variables.
Cc: Abner Chang <abner.chang@amd.com>
Cc: Nickle Wang <nicklew@nvidia.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Signed-off-by: Igor Kulchytskyy <igork@ami.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
The topology of a platform is represented in ACPI using the PPTT
table. It is possible to append information to CPUs/processor
containers using their associated AML nodes in a SSDT
table.
A platform might have multiple 'physical packages' (or top-level
nodes) in their PPTT topology representation. It can be assumed
from [1] that a 'physical packages' is always a 'top-level node',
and conversely.
The SSDT topology generator doesn't support having multiple top-level
nodes. The top-level node is also not generated in the SSDT topology
representation.
Add support to generate multiple top-level nodes in the SSDT topology
generator and generate an AML node for this top-level node. This will
allow to have matching PPTT and SSDT topology representations. Prior
to this patch, this top-level AML node was not generated.
Also factorize the flag checking in CheckProcNode() and add more
checks.
This patch takes inspiration from the discussion at:
- v1: https://edk2.groups.io/g/devel/message/99410
- v2: https://edk2.groups.io/g/devel/message/99615
[1]
ACPI 6.5, 5.2.30.1 Processor hierarchy node structure (Type 0):
- "Multiple trees may be described, covering for example multiple
packages. For the root of a tree, the parent pointer should be 0.""
- "Each valid processor must belong to exactly one package. That is,
the leaf must itself be a physical package or have an ancestor
marked as a physical package."
Suggested-by: Jeff Brasen <jbrasen@nvidia.com>
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Add quotes around the OBJCOPY command in build_rule.template to fix the
case where LLVM is installed on Windows in a path with spaces such as
C:\Program Files\LLVM.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Bug #4414
Add DEBUG_MANAGEABILITY print error lever to
output debug message of detailed manageability
related module information, such as
- RedfishPkg:
- HTTP header/request/response
- JSON plain text
- Refish resource
- Redfish Host interface information
- Redfish credential information
- Platform configuration to Redfish mapping
- etc.
- ManageabilityPKg
- Protocol payload of MCTP/PLDM/IPMI
- Payload of transport interface transfers
- IPMI BLOB transfer
- etc.
- RedfishClinetPkg
- Redfish feature driver dispatcher
- Redfish BIOS attributes
- Platform configuration (HII) to
Redfish property information
- Redfish C structure information
- etc.
Signed-off-by: Abner Chang <abner.chang@amd.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Cc: Nickle Wang <nicklew@nvidia.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Cc: Isaac Oram <isaac.w.oram@intel.com>
Cc: Abdul Lateef Attar <AbdulLateef.Attar@amd.com>
Cc: Tinh Nguyen <tinhnguyen@os.amperecomputing.com>
HostBasedUnitTestRunner.py is a build plugin responsible for locating
and executing host-based unit tests.
Recently, commit 6bb00aa introduced support for the plugin to
generate code coverage reports via lcov and OpenCppCoverage.
The plugin has discovered unit tests by searching for executables
with "Test" in the name for a while. However, the test coverage
change makes assumptions about test presence when crafting the
OpenCppCoverage command that ultimately fails with an ambiguous error
message if no host-based unit tests are discovered (see "ERROR").
```
SECTION - Run Host based Unit Tests
SUBSECTION - Testing for architecture: X64
ERROR - UnitTest Coverage: Failed to generate cobertura format xml in
single package.
PROGRESS - --->Test Success: Host Unit Test Compiler Plugin NOOPT
```
This change preempts that message with a check in the plugin to
determine if any host-based tests were discovered. If not, a message
is printed with more guidance about how the developer should proceed
to either (1) fix their tests so code coverage is generated as
expected or (2) prevent the error message.
New message:
```
SECTION - Run Host based Unit Tests
SUBSECTION - Testing for architecture: X64
WARNING - UnitTest Coverage:
No unit tests discovered. Test coverage will not be generated.
Prevent this message by:
1. Adding host-based unit tests to this package
2. Ensuring tests have the word "Test" in their name
3. Disabling HostUnitTestCompilerPlugin in the package CI YAML file
PROGRESS - --->Test Success: Host Unit Test Compiler Plugin NOOPT
```
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>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
As the ASM_FUNC() macro performs a section switch, the preceding
.balign directive applies the alignment constraint to the current
location in the previous section. As the linker may not merge the
sections in-order, ArmReplaceLiveTranslationEntry() may be left
unaligned.
Replace the explicit invocation of .balign with the ASM_FUNC_ALIGN()
macro, which guarantees the alignment constraint is applied correctly.
To make sure related issues are reliably caught in the future, align the
end of the function before checking the total occupied size. This
ensures crossing a 0x200 boundary will cause a compilation error.
Signed-off-by: Marvin Häuser <mhaeuser@posteo.de>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
With the current ASM_FUNC() macro, there is no good way to declare an
alignment constraint for a function. As ASM_FUNC() switches sections,
declaring the constraint before the macro invocation applies it to the
current location in the previous section. Declaring the constraint after
the macro invocation lets the function label point to the location prior
to alignment. Depending on toolchain behaviour, this may cause the label
to point to alignment padding preceding the actual function definition.
To address these issues, introduce the ASM_FUNC_ALIGN() macro, which
declares the alignment constraint right before the function label.
Signed-off-by: Marvin Häuser <mhaeuser@posteo.de>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Add a .git-blame-ignore-revs file containing the hashes of every
uncrustify format commit as retrieved in:
git log --oneline --no-abbrev-commit | grep "uncrustify"
This file can be used by tools (such as GitHub[1]) to ignore
certain revisions when git blame-ing a file.
It can also be trivially usable locally by doing something akin
to:
git config blame.ignoreRevsFile .git-blame-ignore-revs
It may also be desirable in the future to add more commits to it.
Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
Cc: Andrew Fish <afish@apple.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
[1]: https://github.blog/changelog/2022-03-24-ignore-commits-in-the-blame-view-beta/
To help people format patches with the correct options, add an alias
named 'fp' to SetupGit.py that runs format-patch with '-M --stat=1000
--stat-graph-width=20'.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
New code should use the C99 macro __func__ instead of the pre-Standard
macro __FUNCTION__. Update PatchCheck.py to reject patches with the
latter.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Add a new library, JedecJep106Lib which provides a service to return the
JEDEC JEP106 manufacturer string given the code and continuation bytes
values.
Signed-off-by: Rebecca Cran <rebecca@quicinc.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.
Since it's more standard, replace __FUNCTION__ with __func__ throughout
FmpDevicePkg.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Wei6 Xu <wei6.xu@intel.com>
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.
Since it's more standard, replace __FUNCTION__ with __func__ throughout
UefiPayloadPkg.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Gua Guo <gua.guo@intel.com>
Reviewed-by: James Lu <james.lu@intel.com>
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.
Since it's more standard, replace __FUNCTION__ with __func__ throughout
EmulatorPkg.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Abner Chang <Abner.Chang@amd.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.
Since it's more standard, replace __FUNCTION__ with __func__ throughout
SourceLevelDebugPkg.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Ray Ni <ray.ni@intel.com>
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.
Since it's more standard, replace __FUNCTION__ with __func__ throughout
NetworkPkg.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.
Since it's more standard, replace __FUNCTION__ with __func__ throughout
CryptoPkg.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.
Since it's more standard, replace __FUNCTION__ with __func__ throughout
StandaloneMmPkg.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.
Since it's more standard, replace __FUNCTION__ with __func__ throughout
PrmPkg.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.
Since it's more standard, replace __FUNCTION__ with __func__ throughout
UnitTestFrameworkPkg.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.
Since it's more standard, replace __FUNCTION__ with __func__ throughout
ArmPlatformPkg.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.
Since it's more standard, replace __FUNCTION__ with __func__ throughout
RedfishPkg.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Nickle Wang <nicklew@nvidia.com>
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.
Since it's more standard, replace __FUNCTION__ with __func__ throughout
EmbeddedPkg.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Abner Chang <abner.chang@amd.com>
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.
Since it's more standard, replace __FUNCTION__ with __func__ throughout
SecurityPkg.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.
Since it's more standard, replace __FUNCTION__ with __func__ throughout
MdeModulePkg.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.
Since it's more standard, replace __FUNCTION__ with __func__ throughout
OvmfPkg.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.
Since it's more standard, replace __FUNCTION__ with __func__ throughout
UefiCpuPkg.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.
Since it's more standard, replace __FUNCTION__ with __func__ throughout
ArmVirtPkg.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.
Since it's more standard, replace __FUNCTION__ with __func__ throughout
ArmPkg.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Update PrmPkg host-based unit test INF files to only list
VALID_ARCHITECTURES of IA32 and X64 to align with all other
host-based unit test INF files. The UnitTestFrameworkPkg only
provides build support of host-based unit tests to OS applications
for IA32 and X64.
Cc: Michael Kubacki <mikuback@linux.microsoft.com>
Cc: Nate DeSimone <nathaniel.l.desimone@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Reviewed-by: Michael Kubacki <mikuback@linux.microsoft.com>
Update MdeModulePkg host-based unit test INF files to only list
VALID_ARCHITECTURES of IA32 and X64 to align with all other
host-based unit test INF files. The UnitTestFrameworkPkg only
provides build support of host-based unit tests to OS applications
for IA32 and X64.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Update BaseLib host-based unit test INF file to only list
VALID_ARCHITECTURES of IA32 and X64 to align with all other
host-based unit test INF files. The UnitTestFrameworkPkg only
provides build support of host-based unit tests to OS applications
for IA32 and X64.
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Update SecureBootVariableLib host-based unit test INF file to only
list VALID_ARCHITECTURES of IA32 and X64 to align with all other
host-based unit test INF files. The UnitTestFrameworkPkg only
provides build support of host-based unit tests to OS applications
for IA32 and X64.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Oliver Smith-Denny <osde@linux.microsoft.com>
The unit test code for the SecureBootVariableLib is initializing
local variable structures in their declaration from other local
variables that are also initialized in their declaration. ANSI C
does not allow this and error 4122 is generated on VS20xx compilers.
The test cases are updated to initialize the local structure
fields in C statements instead of their local variable declaration.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Oliver Smith-Denny <osde@linux.microsoft.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4405
The memory attributes table has been extended with a flag that indicates
whether or not the OS is permitted to map the EFI runtime code regions
with strict enforcement for IBT/BTI landing pad instructions.
Given that the PE/COFF spec now defines a DllCharacteristicsEx flag that
indicates whether or not a loaded image is compatible with this, we can
wire this up to the flag in the memory attributes table, and set it if
all loaded runtime image are compatible with it.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
The generic and XCODE5 versions of this library are now identical, so
drop the special case. The library will be removed entirely in a
subsequent patch.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Jiewen Yao <jiewen.yao@intel.com>
The CPU exception handler library code was rewritten at some point to
populate the vector code templates with absolute references at runtime,
given that the XCODE linker does not permit absolute references in
executable code when creating PIE executables.
This is rather unfortunate, as this prevents us from using strict
permissions on the memory mappings, given that the .text section needs
to be writable at runtime for this arrangement to work.
So let's make this hack XCODE-only, by setting a preprocessor #define
from the command line when using the XCODE toolchain, and only including
the runtime fixup code when the macro is defined.
While at it, rename the Xcode5ExceptionHandlerAsm.nasm source file and
drop the Xcode5 prefix: this code is used by other toolchains too.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Ray Ni <ray.ni@intel.com>
The PEI flavor of CpuExceptionHandlerLib never populates more than 32
IDT vectors, and there is no CET shadow stack support in the PEI phase.
So there is no need to use the generic ExceptionHandler NASM source,
which carries a 256-entry template and CET support, and writes to its
own .text section when built using XCODE, which is not permitted in the
PEI phase. So let's switch to the reduced SEC/PEI version of this
component, which is sufficient for PEI and doesn't suffer from the same
issue.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Currently, we use the non-Xcode5 version of ExceptionHandlerAsm.nasm
only for the SEC and PEI phases, and this version was not compatible
with the XCODE or LLD linkers, which do not permit absolute relocations
in read-only sections.
Given that SEC and PEI code typically executes in place from flash and
does not use page alignment for sections, we can simply emit the code
carrying the absolute symbol references into the .data segment instead.
This works around the linker's objections, and the resulting image will
be mapped executable in its entirety anyway. Since this is only needed
for XCODE, let's make this change conditionally using a preprocessor
macro.
Let's rename the .nasm file to reflect the fact that is used for the
SecPei flavor of this library only, and while at it, remove some
unnecessary absolute references.
Also update the Xcode specific version of this library, and use this
source file instead. This is necesessary, as the Xcode specific version
modifies its own code at runtime, which is not permitted in SEC or PEI.
Note that this also removes CET support from the Xcode5 specific build
of the SEC/PEI version of this library, but this is not needed this
early in any case, and this aligns it with other toolchains, which use
this version of the library, which does not have CET support either.
1. Change for non-XCODE SecPeiCpuExceptionHandlerLib:
. Use SecPeiExceptionHandlerAsm.nasm (renamed from
ExceptionHandlerAsm.nasm)
. Removed some unnecessary absolute references
(32 IDT stubs are still in .text.)
2. Change for XCODE SecPeiCpuExceptionHandlerLib:
. Use SecPeiExceptionHandlerAsm.nasm instead of
Xcode5ExceptionHandlerAsm.nasm
. CET logic is not in SecPeiExceptionHandlerAsm.nasm (but aligns to
non-XCODE lib instance)
. Fixed a bug that does runtime fixup in TEXT section in SPI flash.
. Emitted the code carrying the absolute symbol references into the
.data which XCODE or LLD linkers allow.
. Then fixup can be done by other build tools such as GenFv if the code
runs in SPI flash, or by PE coff loader if the code is loaded to
memory.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Ray Ni <ray.ni@intel.com>
We rely on PIE executables to get the codegen that is suitable for
PE/COFF conversion where the resulting executables can be loaded
anywhere in the address space.
However, ELF linkers may default to disallowing text relocations in PIE
executables, as this would require text segments to be updated at
runtime, which is bad for security and increases the copy-on-write
footprint of ELF executables and shared libraries.
However, none of those concerns apply to PE/COFF executables in the
context of EFI, which are copied into memory rather than mmap()'ed, and
fixed up by the loader before launch.
So pass -z notext to the LLD linker to permit runtime relocations in
read-only sections.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Update the antlr makefile to remove the explicit setting of CC to either
clang or gcc. This causes it to use /usr/bin/cc or whatever the user has
set $(CC) to.
This removes the last dependency on gcc for BaseTools.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
The clang toolchain might default to fPIE/fPIC, which prevents
lld from linking the objects into a binary.
Specify -fno-pie -fno-pic as done on GCC to fix linking.
Test:
Building the Universal Payload using the command
'python UefiPayloadPkg/UniversalPayloadBuild.py -a IA32' actually
works.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4356
clang 17 defaults to C++17, where the 'register' keyword is deprecated
and the warning changed to an error. To avoid build errors, compile
against C++14 by specifying '-std=c++14' in CXXFLAGS.
Signed-off-by: Rebecca Cran <rebecca@quicinc.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
In https://bugzilla.tianocore.org/show_bug.cgi?id=2842 clang support was
added by having users specify "make CXX=llvm" when building BaseTools.
The Makefile then sees that and sets CC=$(CLANG_BIN)clang and
CXX=$(CLANG_BIN)clang++. That requires that the executables 'clang' and
'clang++' exist and for example aren't named 'clang-17' and
'clang++-17'. Also, it's an unusual way of specifying the compiler,
since many users will expect to be able to override CC and CXX on the
make command line.
Rework the BaseTools Makefiles removing the 'BUILD_' prefix (BUILD_CC
and BUILD_CXX) and using the standard name 'LDFLAGS' instead of
'LFLAGS'. This allows clang to be used by running
'make -C BaseTools CC=clang CXX=clang++'.
Signed-off-by: Rebecca Cran <rebecca@quicinc.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
In https://bugzilla.tianocore.org/show_bug.cgi?id=2842 clang support was
added by having users specify "make CXX=llvm" when building BaseTools.
The Makefile then sees that and sets CC=$(CLANG_BIN)clang and
CXX=$(CLANG_BIN)clang++. That requires that the executables 'clang' and
'clang++' exist and for example aren't named 'clang-17' and
'clang++-17'. Also, it's an unusual way of specifying the compiler,
since many users will expect to be able to override CC and CXX on the
make command line.
Rework the BaseTools Makefiles removing the 'BUILD_' prefix (BUILD_CC
and BUILD_CXX) and using the standard name 'LDFLAGS' instead of
'LFLAGS'. This allows clang to be used by running
'make -C BaseTools CC=clang CXX=clang++'.
Signed-off-by: Rebecca Cran <rebecca@quicinc.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Bump the version of edk2-basetools in pip-requirements.txt to 0.1.43.
This version contains the update to generate makefiles with both
CFLAGS and BUILD_CFLAGS.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4391
FSP should support the scenario that CPU microcode already loaded
before calling LoadMicrocodeDefault(), in this case it should return
directly without spending more time.
Also the LoadMicrocodeDefault() should only attempt to load one version
of the microcode for current CPU and return directly without parsing
rest of the microcode in FV.
This patch also removed unnecessary LoadCheck code after supporting
CPU microcode already loaded scenario.
Cc: Nate DeSimone <nathaniel.l.desimone@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Chasel Chiu <chasel.chiu@intel.com>
Reviewed-by: Ted Kuo <ted.kuo@intel.com>
Reviewed-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
As recommended by CodeQL this change replaces
cpp/potential-buffer-overflow with cpp/overrunning-write-with-float
and cpp/overrunning-write.
Enables:
1. cpp/overrunning-write
- @name Likely overrunning write
- @description Buffer write operations that do not control the length
data written may overflow
- @kind problem
- @problem.severity error
- @security-severity 9.3
- @precision high
- @id cpp/very-likely-overrunning-write
- @tags reliability
- security
- external/cwe/cwe-120
- external/cwe/cwe-787
- external/cwe/cwe-805
2. cpp/overrunning-write-with-float
- @name Potentially overrunning write with float to string conversion
- @description Buffer write operations that do not control the length
of data written may overflow when floating point inputs
take extreme values.
- @kind problem
- @problem.severity error
- @security-severity 9.3
- @precision medium
- @id cpp/overrunning-write-with-float
- @tags reliability
- security
- external/cwe/cwe-120
- external/cwe/cwe-787
- external/cwe/cwe-805
3. cpp/very-likely-overrunning-write
- @name Likely overrunning write
- @description Buffer write operations that do not control the length
of data written may overflow
- @kind problem
- @problem.severity error
- @security-severity 9.3
- @precision high
- @id cpp/very-likely-overrunning-write
- @tags reliability
- security
- external/cwe/cwe-120
- external/cwe/cwe-787
- external/cwe/cwe-805
- CWEs:
- https://cwe.mitre.org/data/definitions/120.html
- https://cwe.mitre.org/data/definitions/787.html
- https://cwe.mitre.org/data/definitions/805.html
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Michael Kubacki <mikuback@linux.microsoft.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com>
The previous commits fixed issues with these queries across various
packages. Now that those are resolved, enable the queries in the
edk2 query set so regressions can be found in the future.
Enables:
1. cpp/conditionallyuninitializedvariable
- CWE: https://cwe.mitre.org/data/definitions/457.html
- @name Conditionally uninitialized variable
- @description An initialization function is used to initialize a
local variable, but the returned status code is
not checked. The variable may be left in an
uninitialized state, and reading the variable may
result in undefined behavior.
- @kind problem
- @problem.severity warning
- @security-severity 7.8
- @id cpp/conditionally-uninitialized-variable
- @tags security
- external/cwe/cwe-457
2. cpp/pointer-overflow-check
- CWE: https://cwe.mitre.org/data/definitions/758.html
- @name Pointer overflow check
- @description Adding a value to a pointer to check if it
overflows relies on undefined behavior and
may lead to memory corruption.
- @kind problem
- @problem.severity error
- @security-severity 2.1
- @precision high
- @id cpp/pointer-overflow-check
- @tags reliability
- security
- external/cwe/cwe-758
3. cpp/potential-buffer-overflow
- CWE: https://cwe.mitre.org/data/definitions/676.html
- @name Potential buffer overflow
- @description Using a library function that does not check
buffer bounds requires the surrounding program
to be very carefully written to avoid buffer
overflows.
- @kind problem
- @id cpp/potential-buffer-overflow
- @problem.severity warning
- @security-severity 10.0
- @tags reliability
- security
- external/cwe/cwe-676
- @deprecated This query is deprecated, use
Potentially overrunning write
(`cpp/overrunning-write`) and
Potentially overrunning write with float to string
conversion
(`cpp/overrunning-write-with-float`) instead.
Note that cpp/potential-buffer-overflow is deprecated. This query
will be updated to the succeeding queries in the next commit. The
query is used in this commit to show that we considered and tested
the query in history.
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Michael Kubacki <mikuback@linux.microsoft.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com>
Fixes CodeQL alerts for CWE-457:
https://cwe.mitre.org/data/definitions/457.html
Note that this change affects the actual return value from the
following functions. The functions documented that if an integer
overflow occurred, MAX_UINTN would be returned. They were
implemented to actually return an undefined value from the stack.
This change makes the function follow its description. However, this
is technically different than what callers may have previously
expected.
MdePkg/Library/BaseLib/String.c:
- StrDecimalToUintn()
- StrDecimalToUint64()
- StrHexToUintn()
- StrHexToUint64()
- AsciiStrDecimalToUintn()
- AsciiStrDecimalToUint64()
- AsciiStrHexToUintn()
- AsciiStrHexToUint64()
Cc: Erich McMillan <emcmillan@microsoft.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Michael Kubacki <mikuback@linux.microsoft.com>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Co-authored-by: Erich McMillan <emcmillan@microsoft.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com>
While more portable methods exist to handle these cases, this change
does not attempt to do more than fix the immediate problem and
follow the conventions already established in this code.
`snprintf()` is introduced as the minimum improvement apart from
making the buffers larger.
Fixes the following CodeQL alerts:
1. Failure on line 2339 in
BaseTools/Source/C/VfrCompile/Pccts/antlr/gen.c
- Type: Potentially overrunning write
- Severity: Critical
- Problem: This 'call to sprintf' operation requires 17 bytes but
the destination is only 16 bytes.
2. Failure on line 2341 in
BaseTools/Source/C/VfrCompile/Pccts/antlr/gen.c
- Type: Potentially overrunning write
- Severity: Critical
- Problem: This 'call to sprintf' operation requires 17 bytes but
the destination is only 16 bytes.
3. Failure on line 1309 in
BaseTools/Source/C/VfrCompile/Pccts/antlr/main.c
- Type: Potentially overrunning write
- Severity: Critical
- Problem: This 'call to sprintf' operation requires 25 bytes but
the destination is only 20 bytes.
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Yuwei Chen <yuwei.chen@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: Oliver Smith-Denny <osd@smith-denny.com>
Purdue Compiler Construction Tool Set (PCCTS) source code was copied/
pasted into BaseTools/Source/C/VfrCompile/Pccts/.
The code contains tab characters instead of spaces.
PatchCheck.py gives an error on modifications to files that
contain tabs.
The goal of my upcoming change there is not to mix tabs and spaces
but to fix a bug while preserving its current formatting characters.
This change adds that directory to the pre-existing list of
directories in which tab checks are ignored in PatchCheck.py
and also updates the check for makefiles to check for *.makefile:
this allows {header,footer,app,lib}.makefile in
BaseTools/Source/C/Makefiles to be detected and avoid having
PatchCheck.py complain about tab characters.
The check for "Makefile" is updated to be case-insensitive since
there are some Makefiles named 'makefile' instead of 'Makefile'.
Co-authored-by: Rebecca Cran <rebecca@bsdio.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Yuwei Chen <yuwei.chen@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: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com>
Drop MtrrLibIsPowerOfTwo function, use the new IS_POW2() macro instead.
The ASSERT() removed (inside MtrrLibIsPowerOfTwo) is superfluous,
another ASSERT() a few lines up in MtrrLibCalculateMtrrs() already
guarantees that Length can not be zero at this point.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
ALIGNOF: Determining the alignment requirement of data types is
crucial to ensure safe memory accesses when parsing untrusted data.
IS_POW2: Determining whether a value is a power of two is important
to verify whether untrusted values are valid alignment values.
IS_ALIGNED: In combination with ALIGNOF data offsets can be verified.
A more general version of the IS_ALIGNED macro previously defined by
several modules.
ADDRESS_IS_ALIGNED: Variant of IS_ALIGNED for pointers and addresses.
Replaces module-specific definitions throughout the code base.
ALIGN_VALUE_ADDEND: The addend to align up can be used to directly
determine the required offset for data alignment.
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Cc: Vitaly Cheptsov <vit9696@protonmail.com>
Signed-off-by: Marvin Häuser <mhaeuser@posteo.de>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
This patch is a preparation for the patches that follow. The
subsequent patches will introduce and integrate new alignment-related
macros, which collide with existing definitions in OvmfPkg.
Temporarily rename them to avoid build failure, till they can be
substituted with the new, shared definitions.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
This patch is a preparation for the patches that follow. The
subsequent patches will introduce and integrate new alignment-related
macros, which collide with existing definitions in MdeModulePkg.
Temporarily rename them to avoid build failure, till they can be
substituted with the new, shared definitions.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Marvin Häuser <mhaeuser@posteo.de>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4353
Due to AMD erratum #1467, an SEV-SNP VMSA should not be 2MB aligned. To
work around this issue, allocate two pages instead of one. Because of the
way that page allocation is implemented, always try to use the second
page. If the second page is not 2MB aligned, free the first page and use
the second page. If the second page is 2MB aligned, free the second page
and use the first page. Freeing in this way reduces holes in the memory
map.
Fixes: 06544455d0 ("UefiCpuPkg/MpInitLib: Use SEV-SNP AP Creation ...")
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Ray Ni <ray.ni@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=4353
When parking the APs on exiting from UEFI, a new page allocation is made.
This allocation, however, does not end up being marked reserved in the
memory map supplied to the OS. To avoid this, re-use the VMSA by clearing
the VMSA RMP flag, updating the page contents and re-setting the VMSA RMP
flag.
Fixes: 06544455d0 ("UefiCpuPkg/MpInitLib: Use SEV-SNP AP Creation ...")
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Ray Ni <ray.ni@intel.com>
BufferPages is UINTN, so we need "%Lu" when printing it to avoid
it being truncated. Also cast to UINT64 to make sure it works
for 32bit builds too.
Fixes: 4f441d024b ("UefiCpuPkg/PiSmmCpuDxeSmm: fix error handling")
Reported-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
TME (Total Memory Encryption) is the capability to encrypt
the entirety of physical memory of a system.
TME-MK (Total Memory Encryption-Multi-Key) builds on TME and adds
support for multiple encryption keys.
The patch adds some necessary CPUID/MSR definitions for TME-MK.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=4011
Currently AHCI driver will try to retry all failed packets
regardless of the failure cause. This is a problem in password
unlock flow where number of password retries is tracked by the
device. If user passes a wrong password Ahci driver will try
to send the wrong password multiple times which will exhaust
number of password retries and force the user to restart the
machine. This commit introduces a logic to check for the cause
of packet failure and only retry packets which failed due to
transient conditions on the link. With this patch only packets for
which CRC error is flagged are retried.
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Hunter Chang <hunter.chang@intel.com>
Cc: Baraneedharan Anbazhagan <anbazhagan@hp.com>
Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Baraneedharan Anbazhagan <anbazhagan@hp.com>
Add bounds checks of PcdRtcDefaultYear to guarantee that the year
is always between PcdMinimalValidYear and PcdMaximalValidYear.
This is required to make the following commit a backwards compatible
change and guarantee and invalid year is never set.
d55d73152e
This is required because use of an expression in the DEC file
PCD default value is only used to determine the DEC default values.
If an INF/DSC overrides PcdRtcDefaultYear, then the DEC expression
for PcdMinimalValidYear is not applied again.
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
This library follows Redfish Host Interface specification and use IPMI
command to get bootstrap account credential(NetFn 2Ch, Command 02h)
from BMC. RedfishHostInterfaceDxe will use this credential for the
following communication between BIOS and BMC.
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>
The IdMap.S asm source file has not executable content, but its lack of
a BTI annotation prevents the linker from marking any executables it
emits as BTI compatible if this object is part of the build. So add the
BTI note by hand.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
The object file containing the vector table does not contain any
callable functions, so it will not be implicitly annotated as BTI
compatible on BTI builds. So add the annotation by hand, and use the
'empty' type so we get the GNU ELF note but not the actual BTI opcode.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com>
The ELF based toolchains use objcopy to create HII object files, which
contain only a single .hii section. This means no GNU note is inserted
that describes the object as compatible with BTI, even though the lack
of executable code in such an object makes the distinction irrelevant.
However, the linker will not add the note globally to the resulting ELF
executable, and this breaks BTI compatibility.
So let's insert a GNU BTI-compatible ELF note by hand when generating
such object files.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com>
The GccLto helper library does not contain any code, as its only purpose
is to pull in other libraries that implement intrinsics to which the
linker's codegen pass may emit calls.
So mark it as BTI compatible, so that the linker does not complain about
unannotated objects.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com>
When building with -mbranch-protection=bti, which affects the compiler
codegen only, ensure that the assembler based codegen is aligned with
this, by emitting the BTI C opcode at the start of each exported
function. While most exported functions are not in fact ever called
indirectly, whether or not this is the case is a property of the caller
so annotating every exported function is a reasonable default.
While at it, fix two occurrences in ArmPkg of exported functions that
did not use the ASM_FUNC() macro.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com>
Add the BTI instructions and the associated note to make the AArch64 asm
objects compatible with BTI enforcement.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com>
Add the BTI instructions and the associated note to make the AArch64 asm
objects compatible with BTI enforcement.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com>
Add the BTI instructions and the associated note to make the AArch64 asm
objects compatible with BTI enforcement.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com>
Add the BTI instructions and the associated note to make the AArch64 asm
objects compatible with BTI enforcement.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com>
Currently, the AArch64 implementation of LongJump() avoids using the RET
instruction to perform the jump, even though the target address is held
in the link register X30, as the nature of a long jump implies that the
ordinary return address prediction machinery will not be able to make a
correct prediction.
However, LongJump() is rarely used, and the return stack will be out of
sync in any case, so this optimization has little value in practice, and
given that indirect calls other than function returns require a BTI
landing pad at the call site, this optimization is not compatible with
BTI. So let's just use RET instead.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com>
Add the BTI instructions and the associated note to make the AArch64 asm
objects compatible with BTI enforcement.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com>
Add the BTI instructions and the associated note to make the AArch64 asm
objects compatible with BTI enforcement.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com>
Implement a CPP macro that can be called from .S files to emit the .note
section carrying the annotation that informs the linker that the object
file is compatible with BTI control flow integrity checks.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com>
The Rtc library for the kvmtool guest firmware configures the
RTC controller address range as runtime memory by calling the
gDS->SetMemorySpaceAttributes().
The SetMemorySpaceAttributes() function has a dependency on
the CPU Arch Protocol. If the CPU Arch Protocol is not
installed the call to set the memory attributes fails with
error code EFI_NOT_AVAILABLE_YET.
Therefore, set the library dependency on the CPU Arch protocol.
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
When scanning for the Serial Port in the device
tree, the length and value parameters to ScanMem8()
are not in the right order. This results in the
serial port not being detected if the chosen node
in the device tree has additional elements.
Therefore, pass the parameters to ScanMem8() in the
correct order to fix this issue.
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
When scanning for the Serial Port in the device
tree, the length and value parameters to ScanMem8()
are not in the right order. This results in the
serial port not being detected if the chosen node
in the device tree has additional elements.
Therefore, pass the parameters to ScanMem8() in the
correct order to fix this issue.
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reduce the log output from Configuration Manager Object Parser
in TableHelperLib by enabling the logs only if DEBUG_INFO is
enabled.
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
The CLANGDWARF toolchain has the same problem as XCODE5 linking
CpuExceptionHandlerLib. So, use the
Xcode5SecPeiCpuExceptionHandlerLib.inf when building with the CLANGDWARF
toolchain.
Since the difference is that the non-Xcode5 version uses `mov` while the
Xcode5 version uses `lea`, they can be merged in future with the single
version using `lea`.
[ardb: the main difference is that the 'mov' instructions result in
absolute symbol references, which are necessary because the code
in question is copied in memory independently from the code that
carries the symbols it refers to. The Xcode5 version has
additional runtime handling to fix up the copied code with the
correct absolute references.]
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Bug fix:
- function stack fault
- properly handle "SubnetAddrInfoIPv6" when there is no IPv6 support
- copy-n-paste error in RedfishGetHostInterfaceProtocolData()
- fix typo
Enhancement:
- Redfish discover driver now can configure host IP address based on
the information from SMBIOS type 42 record. This saves the effort of
configuring host IP address in setup menu.
- Performance improvement to driver binding process. Redfish discover
driver will wait until all required drivers are ready and do driver
binding start().
- Use CopyGuid() to copy GUID instead of intrinsic function.
- Error handling when SMBIOS data is corrupted.
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: Abner Chang <abner.chang@amd.com>
commit f13264b34 introduces a bug for CloudHv as OvmfPkg/OvmfPkg.dec is
missing in CloudHvHasAcpiDtDxe.inf which leads to
gUefiOvmfPkgTokenSpaceGuid found nowhere when build.
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
The BIOS Firmware Version in the SMBIOS Type 0 can be fetched from
the fixed PcdFirmwareVersionString or platform specific OemMiscLib.
In fact, the support from OemMiscLib comes into play when the firmware
version may be modified at boot time for extended information.
Therefore, the priority of getting the version from OemMiscLib should
be higher.
In case there is no modification in the OemMiscLib, we have to keep
HII string STR_MISC_BIOS_VERSION empty or 'Not Specified'
to indicate that the firmware version should be fetched from
the PcdFirmwareVersionString.
Signed-off-by: Tinh Nguyen <tinhnguyen@os.amperecomputing.com>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
With the new mmconfig location at 0xe0000000 above the 32-bit PCI MMIO
window we don't have to special-case the mmconfig xbar any more. We'll
just add a mtrr uncachable entry starting at MMIO window base and ending
at 4GB.
Update comments to match reality.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Also swap the ordering of 32bit PCI MMIO window on q35, i.e. use the
room between end of low memory and the start of the mmconfig bar.
With a typical configuration on modern qemu with gigabyte-aligned memory
the MMIO window start at 0x8000000, sized 1532 MB. In case there is
memory present above 0x80000000 the window will start at 0xc0000000
instead, with 512 MB size.
This depends on qemu commit 4a4418369d6d ("q35: fix mmconfig and
PCI0._CRS"), so it raises the bar for the lowest supported version
to qemu 4.1 (released Aug 2019).
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Move the commment up so it is placed just before the address space
calculations start. Also add q35 memory layout.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
M-mode firmware ranges should not be used by EDK2/OS.
Currently, we search for mmode_resv0 node in FDT and mark it as the
reserved memory in EFI memory map. However, if there are multiple
M-mode firmware ranges, then this will miss those extra ranges
allowing the OS to access the memory and hit a fault.
This issue is exposed since recent opensbi started creating
two ranges for text and data.
Fix this by searching for all reserved memory nodes and marking
them as reserved in the EFI memory map.
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: Andrei Warkentin <andrei.warkentin@intel.com>
Signed-off-by: Sunil V L <sunilvl@ventanamicro.com>
Reviewed-by: Andrei Warkentin <andrei.warkentin@intel.com>
Reduce the number of random tests. In previous patch, non-1:1
mapping is enbaled and it may need more than an hour and a half
for the CI test, which may lead to CI timeout. Reduce the number
of random test count to pass the CI.
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>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Modify CpuPageTableLib code to enable PAE paging.
In PageTableMap() API:
When creating new PAE page table, after creating page table,
set all MustBeZero fields of 4 PDPTE to 0. The MustBeZero
fields are treated as RW and other attributes by the common
map logic. So they might be set to 1.
When updating exsiting PAE page table, the special steps are:
1.Prepare 4K-aligned 32bytes memory in stack for 4 temp PDPTE.
2.Copy original 4 PDPTE to the 4 temp PDPTE and set the RW,
UserSupervisor to 1 and set Nx of 4 temp PDPTE to 0.
4.After updating the page table, set the MustBeZero fields of
4 temp PDPTE to 0.
5.Copy the temp PDPTE to original PDPTE.
In PageTableParse() API, also create 4 temp PDPTE in stack.
Copy original 4 PDPTE to the 4 temp PDPTE. Then set the RW,
UserSupervisor to 1 and set Nx of 4 temp PDPTE to 0. Finally
use the address of temp PDPTE as the page table address.
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>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Combine 'if' condition branch for non-present and leaf Parent
Entry in PageTableLibMapInLevel. Most steps of these two condition
are the same. This commit doesn't change any functionality.
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>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Add code to compare ParentPagingEntry Attribute&Mask and input
Attribute&Mask to decide if new next level page table is needed
in non-present ParentPagingEntry condition. This can help avoid
unneccessary page table creation.
For example, there is a page table in which [0, 1G] is mapped(Lv4[0]
,Lv3[0,0], a non-leaf level4 entry and a leaf level3 entry).And we
only want to map [1G, 1G+2M] linear address still as non-present.
The expected behaviour should be nothing happens in the process.
However, previous code logic doesn't check if ParentPagingEntry
Attribute&Mask and input Attribute&Mask are the same in non-present
ParentPagingEntry condition. Then a new 4K memory is allocated for
Lv2 since 1G+2M is not 1G-aligned.
So when ParentPagingEntry is non-present, before allocate 4K memory
for next level paging, we also check if ParentPagingEntry Attribute&
Mask and input Attribute&Mask are the same.
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>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
The definition of IA32_MAP_ATTRIBUTE has 64 bits, and one of the bit
field PageTableBaseAddress is from bit 12 to bit 52. This means if the
compiler treats the 64bits value as two UINT32 value, the field
PageTableBaseAddress spans two UINT32 value. That's why when building in
NOOPT mode in IA32, the below issue is noticed:
unresolved external symbol __allshl
This patch fix the build failure by seperate field PageTableBaseAddress
into two fields, make sure no field spans two UINT32 value.
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
Signed-off-by: Ray Ni <ray.ni@intel.com>
Add OUTPUT IsModified parameter in PageTableMap() to indicate
if page table has been modified. With this parameter, caller
can know if need to call FlushTlb when the page table is in CR3.
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>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Enable non-1:1 mapping in random test. In previous test, non-1:1
test will fail due to the non-1:1 mapping issue in CpuPageTableLib
and invalid Input Mask when creating new page table or mapping
not-present range. Now these issue have been fixed.
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>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Modify RandomTest to check invalid input. When creating new page
table or updating exsiting page table:
1.If set [LinearAddress, LinearAddress+Length] to non-present, all
other attributes should not be provided.
2.If [LinearAddress, LinearAddress+Length] contain non-present range,
the Returnstatus of PageTableMap() should be InvalidParameter when:
2.1Some of attributes are not provided when mapping non-present range
to present.
2.2Set any other attribute without setting the non-present range to
Present.
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>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Add an input parameter to control the probability of returning
true. Change RandomBoolean() in RandomTest from 50% chance
returning true to returning true with the percentage of input
Probability.
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>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Add manual test case to check input Mask and Attribute. The check
steps are:
1.Create Page table to cover [0, 2G]. All fields of MapMask should
be set.
2.Update Page table to set [2G - 8K,2G] from present to non-present.
All fields of MapMask except present should not be set.
3.Still set [2G - 8K, 2G] as not present, this case is permitted.
But set [2G - 8K, 2G] as RW is not permitted.
4.Update Page table to set [2G - 8K, 2G] as present and RW. All
fields of MapMask should be set.
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>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
For different usage, check if the combination for Mask and
Attr is valid when creating or updating page table.
1.For non-present range
1.1Mask.Present is 0 but some other attributes is provided.
This case is invalid.
1.2Mask.Present is 1 and Attr.Present is 0. In this case,all
other attributes should not be provided.
1.3Mask.Present is 1 and Attr.Present is 1. In this case,all
attributes should be provided to intialize the attribute.
2.For present range
2.1Mask.Present is 1 and Attr.Present is 0.In this case, all
other attributes should not be provided.
All other usage for present range is permitted.
In the mentioned cases, 1.2 and 2.1 can be merged into 1 check.
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>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
When splitting leaf parent entry to smaller granularity, create
child page table before modifing parent entry. In previous code
logic, when splitting a leaf parent entry, parent entry will
point to a null 4k memory before child page table is created in
this 4k memory. When the page table to be modified is the page
table in CR3, if the executed CpuPageTableLib code is in the
range mapped by the modified leaf parent entry, then issue will
happen.
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>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Clear PageSize bit(Bit7) for non-leaf entry in PageTableLibSetPnle.
This function is used to set non-leaf entry attributes so it should
make sure that the PageSize bit of the entry should be 0.
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>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
In previous code logic, when splitting a leaf parent entry to
smaller granularity child page table, if the parent entry
Attribute&Mask(without PageTableBaseAddress field) is equal to the
input attribute&mask(without PageTableBaseAddress field), the split
process won't happen. This may lead to failure in non-1:1 mapping.
For example, there is a page table in which [0, 1G] is mapped(Lv4[0]
,Lv3[0,0], a non-leaf level4 entry and a leaf level3 entry). And we
want to remap [0, 2M] linear address range to [1G, 1G + 2M] with the
same attibute. The expected behaviour should be: split Lv3[0,0]
entry into 512 level2 entries and remap the first level2 entry to
cover [0, 2M]. But the split won't happen in previous code since
PageTableBaseAddress of input Attribute is not checked.
So, when checking if a leaf parent entry needs to be splitted, we
should also check if PageTableBaseAddress calculated by parent entry
is equal to the value caculated by input attribute.
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>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Remove unneeded 'if' condition in CpuPageTableLib code.
The deleted code is in the code branch for present non-leaf parent
entry. So the 'if' check for (ParentPagingEntry->Pnle.Bits.Present
== 0) is always FALSE.
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>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Add PcdRtcDefaultYear to specify the default year to use when
the RTC is in an invalid state. Make sure PcdRtcDefaultYear is
>= PcdMinimalValidYear and <= PcdMaximalValidYear. Set the
default value for this PCD to PcdMinimalValidYear to preserve
the existing behavior. A platform DSC file can override this
default value setting.
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Itanium support has been removed from EDK2 around 2019.
ITANIUM_HANDOFF_STATUS data structure looks to be
some leftover from that process.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1560
GitHub: 4e1daa60f5
There is also positive side effect of this data structure removal.
Due to HOB allocation type used in PEI stage there is a limit
how much data about virtual CPU can be hold. This limit result
in only 1024 vCPU can be used by VM.
With Itanium related data structure removed more allocated space
can be used for vCPU data and with current allocation limit
will change from 1024 to around 8k vCPUs.
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Signed-off-by: Paweł Poławski <ppolawsk@redhat.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Replace the duplicate __PcdSet prototype in PcdValueCommon.h
with the prototype for __PcdGet.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Move the documentation blocks from between the parameter list and function
body to above the function.
Convert all the documentation blocks to Doxygen format.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Time to leave behind relics from the last century and arrive in the
modern world. Drop PC-ANSI Terminal Type for the serial console, use
UTF-8 instead.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
ASSERT() is not proper handling of allocation failures, it gets compiled
out on RELEASE builds. Print a message and enter dead loop instead.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Call gRT->GetVariable() directly to read the SecureBoot variable. It is
one byte in size so we can easily place it on the stack instead of
having GetEfiGlobalVariable2() allocate it for us, which avoids a few
possible error cases.
Skip secure boot checks if (and only if):
(a) the SecureBoot variable is not present (EFI_NOT_FOUND) according to
the return value, or
(b) the SecureBoot variable was read successfully and is set to
SECURE_BOOT_MODE_DISABLE.
Previously the code skipped the secure boot checks on *any*
gRT->GetVariable() error (GetEfiGlobalVariable2 sets the variable
value to NULL in that case) and also on memory allocation failures.
Fixes: CVE-2019-14560
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=2167
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Suggested-by: Marvin Häuser <mhaeuser@posteo.de>
Reviewed-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.
Since it's more standard, replace __FUNCTION__ with __func__ throughout
MdePkg.
Visual Studio versions before VS 2015 don't support __func__ and so
will fail to compile. A workaround is to define __func__ as
__FUNCTION__ :
#define __func__ __FUNCTION__
Signed-off-by: Rebecca Cran <rebecca@quicinc.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
With the introduction of the use of _Static_assert, edk2 requires a C11
compatible compiler. Update Include/Base.h to be compliant with C11.
As of C11, the maximum type of an enum is type `int`. Since the UEFI
Specification 2.3.1 Errata C allows either `int` or `unsigned int`, fix
the 32-bit enum check to use a signed int.
Since the UEFI 2.3 Specification only allowed signed int, update the
comment to reference 2.3.1 Errata C where the change was made to allow
unsigned int.
Signed-off-by: Rebecca Cran <rebecca@quicinc.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
The PEI flavor of the ArmMmuLib will install a HOB that exposes its
implementation of the special helper routine that is used to update live
entries, so that other instantiations of ArmMmuLib can invoke it. This
is needed to ensure that splitting page tables using break-before-make
(BBM) does not unmap the code that is performing the split.
However, the BASE variety of ArmMmuLib discovers the HOB and sets a
global pointer to refer to it, which is not possible in PEIMs, and so
all PEIMs must use the PEI variety of this library if one does.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
To prepare for the enablement of booting EFI with the SCTLR.WXN control
enabled, which makes all writeable memory regions non-executable by
default, introduce a memory type that we will use to describe the flash
region that carries the SEC and PEIM modules that execute in place. Even
if these are implicitly read-only due to the ROM nature, they need to be
mapped with read-only attributes in the page tables to be able to
execute from them.
Also add the XP counterpart which will be used for all normal DRAM right
at the outset.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Non-secure memory is a distinction that only matters when executing code
in the secure world that reasons about the secure vs non-secure address
spaces. EDK2 was not designed for that, and the AArch64 version of the
MMU handling library already treats them as identical, so let's just
drop the ARM memory region types that mark memory as 'non-secure'
explicitly.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Expose the protocol introduced in v2.10 that permits the caller to
manage mapping permissions in the page tables.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
In preparation for introducing an implementation of the EFI memory
attributes protocol that is shared between ARM and AArch64, unify the
existing code that converts a page table descriptor into a
EFI_MEMORY_xx bitfield, so it can be called from the generic code.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Currently, the ARM MMU page table logic will break down any block entry
that overlaps with the region being mapped, even if the block entry in
question is using the same attributes as the new region.
This means that creating a non-executable mapping inside a region that
is already mapped non-executable at a coarser granularity may trigger a
call to AllocatePages (), which may recurse back into the page table
code to update the attributes on the newly allocated page tables.
Let's avoid this, by preserving the block entry if it already covers the
region being mapped with the correct attributes.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Enable the stack guard in ArmVirtPkg builds, so that stack overflows are
caught as they occur, rather than when they happen to hit a read-only
memory region.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Implement support for read-protected memory by wiring it up to the
access flag in the page table descriptor. The resulting mapping is
implicitly non-writable and non-executable as well, but this is good
enough for implementing this attribute, as we never rely on write or
execute permissions without read permissions.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Currently, the MMU code that is supposed to clear the RO or XP
attributes from a region just clears both unconditionally. This
approximates the desired behavior to some extent, but it does mean that
setting the RO bit first on a code region, and then clearing the XP bit
results both RO and XP being cleared, and we end up with writable code,
and avoiding that is the point of all these protections.
Once we introduce RP support, this will only get worse, so let's fix
this up, by reshuffling the attribute update code to take the entry mask
from the caller, and use the mask to preserve other attributes when
clearing RO or XP.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Split the ARM permission fields in the short descriptors into an access
flag and AP[2:1] as per the recommendation in the ARM ARM. This makes
the access flag available separately, which allows us to implement
EFI_MEMORY_RP memory analogous to how it will be implemented for
AArch64.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
The section-to-page attribute conversion takes the shareability and
execute-never attributes into account, whereas the page-to-section
counterpart does not. The result is that GetMemoryRegionPage () -which
takes a section attribute argument (via *RegionAttributes) that is
ostensibly based on the first page in the range, but differs from the
actual page attributes when converted back- may return with a
RegionLength of zero. This is incorrect, and confuses code that scans a
region by calling GetMemoryRegion () in sequence.
So fix the conversion, and ASSERT () on a non-zero region length.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
With large page support out of the picture, we can treat bits 1 and 0 of
the page descriptor as individual valid and XN bits, instead of treating
XN as a page type. Doing so aligns the handling of the attribute with
the section descriptor layout, as well as the XN handling on AArch64,
and this is beneficial for maintainability.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Large page support on 32-bit ARM is essentially a glorified contiguous
bit where 16 consecutive entries describing a contiguous range with the
same attributes are presented in a way that permits the TLB to cache its
translation with a single entry.
This was never wired up completely, and does not add a lot of value in
EFI, where the page granularity is 4k and we expect to be able to set RO
and XP permissions on individual pages.
Given that large page support complicates the handling of the XN bit at
the page level (which is in a different place depending on whether the
page is small or large), let's just rip it out.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
When the range instruction cache invalidating not supported, the whole
instruction cache should be invalidated instead.
Signed-off-by: Tuan Phan <tphan@ventanamicro.com>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2850
Add "-Y REPORT_INFO" option to build command to generate compile
information as part of BuildReport.
This option generates files to be used by external tools as IDE's
to enhance functionality.
Files are created inside build folder:
<Build>/<BuildTarget>/<ToolChain>/CompileInfo
Files created:
* compile_commands.json - Compilation Database. To be used by IDE's
to enable advance features
* cscope.files - List of files used in compilation. Used by Cscope to parse
C code and provide browse functionality.
* module_report.json - Module data form buildReport in Json format.
Signed-off-by: Guillermo Antonio Palomino Sosa <guillermo.a.palomino.sosa@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
The Section 6.1.3, SMBIOS specification version 3.6.0 describes the
handling of test strings in SMBIOS tables.
Text strings are added at the end of the formatted portion of the SMBIOS
structure and are referenced by index in the SMBIOS structure.
Therefore, introduce a SmbiosStringTableLib to simplify the publishing
of the string set.
SmbiosStringTableLib introduces a concept of string table which records
the references to the SMBIOS strings as they are added and returns an
string reference which is then assigned to the string field in the
formatted portion of the SMBIOS structure. Once all strings are added,
the library provides an interface to get the required size for the string
set. This allows sufficient memory to be allocated for the SMBIOS table.
The library also provides an interface to publish the string set in
accordance with the SMBIOS specification.
Example:
EFI_STATUS
BuildSmbiosType17Table () {
STRING_TABLE StrTable;
UINT8 DevLocatorRef;
UINT8 BankLocatorRef;
SMBIOS_TABLE_TYPE17 *SmbiosRecord;
CHAR8 *StringSet;
...
// Initialize string table for 7 strings
StringTableInitialize (&StrTable, 7);
StringTableAddString (&StrTable, "SIMM 3", &DevLocatorRef);
StringTableAddString (&StrTable, "Bank 0", &BankLocatorRef);
...
SmbiosRecord = AllocateZeroPool (
sizeof (SMBIOS_TABLE_TYPE17) +
StringTableGetStringSetSize (&StrTable)
);
...
SmbiosRecord->DeviceLocator = DevLocatorRef;
SmbiosRecord->BankLocator = BankLocatorRef;
...
// get the string set area
StringSet = (CHAR8*)(SmbiosRecord + 1);
// publish the string set
StringTablePublishStringSet (
&StrTable,
StringSet,
StringTableGetStringSetSize (&StrTable)
);
// free string table
StringTableFree (&StrTable);
return EFI_SUCCESS;
}
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Cc: Alexei Fedorov <Alexei.Fedorov@arm.com>
Cc: Pierre Gondois <pierre.gondois@arm.com>
Cc: Girish Mahadevan <gmahadevan@nvidia.com>
Cc: Jeff Brasen <jbrasen@nvidia.com>
Cc: Ashish Singhal <ashishsingha@nvidia.com>
Cc: Nick Ramirez <nramirez@nvidia.com>
Cc: William Watson <wwatson@nvidia.com>
Cc: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Because UefiCpuPkg/UefiCpuLib is merged to MdePkg/CpuLib, remove the
dependency of UefiCpuLib.
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Yu Pu <yu.pu@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
There are two libraries: MdePkg/CpuLib and UefiCpuPkg/UefiCpuLib and
UefiCpuPkg/UefiCpuLib will be merged to MdePkg/CpuLib. To avoid build
failure, add CpuLib dependency to all modules that depend on UefiCpuLib.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4360
An incorrect format specifier is being used in a DEBUG print,
specifically, a variable of type EFI_STATUS was being printed with
the %a format specifier (pointer to an ASCII string), thus the value of
the Status variable was being treated as the address of a string,
leading to a CPU exception, when encountered this bug manifests itself
as a hang near "Ready to Boot Event", with the last DEBUG print being
"INFO: Got MicrocodePatchHob with microcode patches starting address"
followed by a CPU Exception dump.
Signed-off-by: Darbin Reyes <darbin.reyes@intel.com>
Reviewed-by: Jacob Narey <jacob.narey@intel.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
In case PcdFirmwareReleaseDateString is not set use a valid date
as fallback. Using "unknown" makes Windows unhappy.
Fixes: 4cb94f20b0 ("OvmfPkg/SmbiosPlatformDxe: use PcdFirmware*")
Reported-by: ruifeng.gao@intel.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
RegisterCpuInterruptHandler did not allow setting
exception handlers for anything beyond the timer IRQ.
Beyond that, it didn't meet the spec around handling
of inputs.
RiscVSupervisorModeTrapHandler now will invoke
set handlers for both exceptions and interrupts.
Two arrays of handlers are maintained - one for exceptions
and one for interrupts.
For unhandled traps, RiscVSupervisorModeTrapHandler dumps
state using the now implemented DumpCpuContext.
For EFI_SYSTEM_CONTEXT_RISCV64, extend this with the trapped
PC address (SEPC), just like on AArch64 (ELR). This is
necessary for X86EmulatorPkg to work as it allows a trap
handler to return execution to a different place. Add
SSTATUS/STVAL as well, at least for debugging purposes. There
is no value in hiding this.
Fix nested exception handling. Handler code should not
be saving SIE (the value is saved in SSTATUS.SPIE) or
directly restored (that's done by SRET). Save and
restore the entire SSTATUS and STVAL, too.
Cc: Daniel Schaefer <git@danielschaefer.me>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
Signed-off-by: Andrei Warkentin <andrei.warkentin@intel.com>
The TimerDxe implementation doesn't account for the physical
time passed due to timer handler execution or (perhaps even
more importantly) time spent with interrupts masked.
Other implementations (e.g. like the Arm one) do. If the
timer tick is always incremented at a fixed rate, then
you can slow down UEFI's perception of time by running
long sections of code in a critical section.
Cc: Daniel Schaefer <git@danielschaefer.me>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
Signed-off-by: Andrei Warkentin <andrei.warkentin@intel.com>
On Arm platforms, the number of available RNG algorithms is
dynamically detected and can be 0 in the absence of FEAT_RNG
and firmware TRNG.
In this case, the EFI_RNG_PROTOCOL should not be installed to
prevent from installing an empty protocol.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
[ardb: return EFI_REQUEST_UNLOAD_IMAGE instead of an error]
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
mAvailableAlgoArrayCount holds the count of available RNG algorithms.
In a following patch, its value will be used to prevent the
EFI_RNG_PROTOCOL to be installed if no RNG algorithm is available.
Correctly set/reset the value for all implementations.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
In openssl 3.0 SHA512() goes through the provider logic,
requiring a huge amount of openssl code. The individual
functions do not, so use them instead.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
In openssl 3.0 SHA384() goes through the provider logic,
requiring a huge amount of openssl code. The individual
functions do not, so use them instead.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
In openssl 3.0 SHA256() goes through the provider logic,
requiring a huge amount of openssl code. The individual
functions do not, so use them instead.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
In openssl 3.0 SHA1() goes through the provider logic,
requiring a huge amount of openssl code. The individual
functions do not, so use them instead.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Add the 'AsmRelocateApLoopStartGeneric' for X64 processors except 64-bit
AMD processors with SEV-ES.
Remove the unused arguments of AsmRelocateApLoopStartGeneric, updated
the stack offset.
Create PageTable for the allocated reserved memory.
Only keep 4GB limitation of memory allocation for the case APs still
need to be transferred to 32-bit mode before OS.
Cc: Guo Dong <guo.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Sean Rhodes <sean@starlabs.systems>
Cc: James Lu <james.lu@intel.com>
Cc: Gua Guo <gua.guo@intel.com>
Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Improve the formatting of DEBUG messages in UsbBusDxe by adding
a hyphen to separate the EFI_STATUS code.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4337
Existing SMBASE Relocation is in the PiSmmCpuDxeSmm driver, which
will relocate the SMBASE of each processor by setting the SMBASE
field in the saved state map (at offset 7EF8h) to a new value.
The RSM instruction reloads the internal SMBASE register with the
value in SMBASE field when each time it exits SMM. All subsequent
SMI requests will use the new SMBASE to find the starting address
for the SMI handler (at SMBASE + 8000h).
Due to the default SMBASE for all x86 processors is 0x30000, the
APs' 1st SMI for rebase has to be executed one by one to avoid
the processors over-writing each other's SMM Save State Area (see
existing SmmRelocateBases() function), which means the next AP has
to wait for the previous AP to finish its 1st SMI, then it can call
into its 1st SMI for rebase via Smi Ipi command, thus leading the
existing SMBASE Relocation has to be running in series. Besides, it
needs very complex code to handle the AP exit semaphore
(mRebased[Index]), which will hook return address of SMM Save State
so that semaphore code can be executed immediately after AP exits
SMM for SMBASE relocation (see existing SemaphoreHook() function).
With SMM Base Hob support, PiSmmCpuDxeSmm does not need the RSM
instruction to do the SMBASE Relocation. SMBASE Register for each
processors have already been programmed and all SMBASE address have
recorded in SMM Base Hob. So the same default SMBASE Address
(0x30000) will not be used, thus the processors over-writing each
other's SMM Save State Area will not happen in PiSmmCpuDxeSmm driver.
This way makes the first SMI init can be executed in parallel and
save boot time on multi-core system. Besides, Semaphore Hook code
logic is also not required, which will greatly simplify the SMBASE
Relocation flow.
Mainly changes as below:
* Assume the biggest possibility of tile size is 8k.
* Combine 2 SMIs (gcSmmInitTemplate & gcSmiHandlerTemplate) into one
(gcSmiHandlerTemplate), the new SMI handler needs to run to 2 paths:
one to SmmCpuFeaturesInitializeProcessor(), the other to SMM Core
Entry Point.
* Issue SMI IPI (All Excluding Self SMM IPI + BSP SMM IPI) for first
SMI init before normal SMI sources happen.
* Call SmmCpuFeaturesInitializeProcessor() in parallel.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zeng Star <star.zeng@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4337
The default SMBASE for the x86 processor is 0x30000. When
SMI happens, processor runs the SMI handler at SMBASE+0x8000.
Also, the SMM save state area is within SMBASE+0x10000.
One of the SMM initialization from processor perspective is to
relocate and program the new SMBASE (in TSEG range) for each
processor. When the SMBASE relocation happens in a PEI module,
the PEI module shall produce the SMM_BASE_HOB in HOB database
which tells the PiSmmCpuDxeSmm driver (runs at a later phase)
about the new SMBASE for each processor. PiSmmCpuDxeSmm driver
installs the SMI handler at the SMM_BASE_HOB.SmBase[Index]+0x8000
for processor Index. When the HOB doesn't exist, PiSmmCpuDxeSmm
driver shall relocate and program the new SMBASE itself.
This patch adds the SMM Base HOB for any PEI module to do
the SmBase relocation ahead of PiSmmCpuDxeSmm driver and
store the relocated SmBase address in array for each
processor.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zeng Star <star.zeng@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ray Ni <ray.ni@Intel.com>
This patch is to replace mIsBsp by mBspApicId check.
mIsBsp becomes the local variable (IsBsp), then it can be
checked dynamically in the function. Instead, we define the
mBspApicId, which is to record the BSP ApicId used for
compare in SmmInitHandler. With this change, SmmInitHandler
can be run in parallel during SMM init.
Note:
This patch is the per-prepared work by refining the
SmmInitHandler, then, we can do the next step to
combine 2 SMIs (gcSmmInitTemplate & gcSmiHandlerTemplate)
into one (gcSmiHandlerTemplate), the new SMI handler
will call the SmmInitHandler in parallel to do the init.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zeng Star <star.zeng@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Introduce RedfishDebugLib to RedfishPkg. This library provides several
debugging functions for Redfish application. Redfish drivers rely on
Rest Ex protocol to communicate with BMC and the communication data
may be big and complicated. Use RedfishDebugLib in RedfishRestExDxe to
simplify debugging process.
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: Abner Chang <abner.chang@amd.com>
The output of the "ping" command shows the time without a space between
the label and the value. e.g.:
20 bytes from 192.168.0.1 : icmp_seq=1 ttl=1 time1~2ms
Improve the readability and consistency by adding an equals sign for the
time value:
20 bytes from 192.168.0.1 : icmp_seq=1 ttl=1 time=1~2ms
Signed-off-by: Rebecca Cran <rebecca@quicinc.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Some platforms don't support S3 with PcdAcpiS3Enable set as False.
Debug mode bios will ASSERT at this time as Follows.
ASSERT_RETURN_ERROR (Status = Out of Resources)
DXE_ASSERT!: Edk2\MdePkg\Library\BaseS3PciSegmentLib\S3PciSegmentLib.c
(61): !(((INTN)(RETURN_STATUS)(Status)) < 0)
Steps to reproduce the issue:
1.Set PcdAcpiS3Enable to FALSE.
2.Build the bios in debug mode.
3.Power on and Check the serial log.
Note: Prerequisite is that S3PciSegmentLib is Called and
the caller's code is run.
Root Cause:
S3PciSegmentLib call S3BootScriptLib controlled by PcdAcpiS3Enable.
If PcdAcpiS3Enable set as false, S3BootScriptLib will return error
status(Out of Resources).
S3PciSegmentLib will ASSERT if S3BootScriptLib return error.
Solution:
Make S3BootScriptLib return success if PcdAcpiS3Enable was disabled,
which behave as a null S3BootScriptLib instance which just return success
for no action is required to do.
Signed-off-by: JunX1 Li <junx1.li@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Sunny Wang <sunny.wang@arm.com>
Cc: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Cc: G Edhaya Chandran <edhaya.chandran@arm.com>
Cc: Samer El-Haj-Mahmoud <samer.el-haj-mahmoud@arm.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Skip error check if HardwareInstance is 0 as this either means that
FmpVersion < 3 and not supported or,
"A zero means the FMP provider is not able to determine a
unique hardware instance number or a hardware instance number
is not needed." per UEFI specification.
As the FmpInstances are merged and HardwareInstance is not used
remove error check in this case.
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
The hard-coded attributes for the re-added memory space should instead
forward the replaced descriptor's capabilities.
Tested on Linux with efi=debug. Prior to this change, an 8GiB VM running
a kernel without unaccepted memory support shows this entry
efi: mem94: [Conventional| | |CC| | | | | | | | | | | ]
range=[0x0000000100000000-0x000000023fffffff] (5120MB)
This does not have the cache capabilities one would expect for system
memory, UC|WC|WT|WB.
After this change, the same entry becomes
efi: mem94: [Conventional| | |CC| | | | | | | |WB|WT|WC|UC]
range=[0x0000000100000000-0x000000023fffffff] (5120MB)
This has all the expected attributes.
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Michael Roth <michael.roth@amd.com>
Signed-off-by: Dionna Glaze <dionnaglaze@google.com>
[ardb: drop the EFI_MEMORY_CPU_CRYPTO flag - it isn't used anywhere else
in EDK2 or Linux so it doesn't actually do anything, and it is
unclear whether it is intended for use by the guest in the first
place]
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Tianocore maintains container images in the tianocore/containers repo
and stores container images within the GitHub container registry.
https://github.com/tianocore/containers
This change adds a devcontainer.json file to the edk2 repo. This
file's metadata and settings to configurate a development container
for a given well-defined tool and runtime stack.
More information about the devcontainer.json file is available here:
https://containers.dev/implementors/json_reference/
This file is recognized by popular tools such as GitHub Codespaces
and VS Code. In VS Code in particular, it makes it much easier for
a user to be aware a dev container exists (via UI notifications)
and to load the container.
A minimal number of VS Code extensions are specified that are useful
for edk2 development or to assist in complying with CI checks in
place in edk2.
Cc: Andrew Fish <afish@apple.com>
Cc: Chris Fernald <chris.fernald@outlook.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Oliver Steffen <osteffen@redhat.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
PR builds and CI are currently broken due to a mergify brownout
today because edk2 uses the `rebase_fallback` attribute of the
`queue` action.
Message from Mergify/Summary:
```
The configuration uses the deprecated rebase_fallback attribute
of the queue action.
A brownout is planned on February 13th, 2023.
This option will be removed on March 13th, 2023.
For more information: https://docs.mergify.com/actions/queue/
```
Therefore, this change removes the attribute per the guidance in
the following changelog message to retain existing behavior.
https://changelog.mergify.com/changelog/rebasefallback-is-deprecated
```
The option rebase_fallback is now deprecated and should not be
used anymore.
Mergify will always report errors in the future if a rebase merge
is impossible.
```
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Since BIOS should work with different BMC implementation chunked requests
as well as Expect header should be optional.
- One PCD is used to enable/disable Expect header.
- Another PCD is used to enable/disable chunked requests.
Reviewed-by: Abner Chang <abner.chang@amd.com>
Cc: Abner Chang <abner.chang@amd.com>
Cc: Nickle Wang <nicklew@nvidia.com>
Signed-off-by: Igor Kulchytskyy <igork@ami.com>
Currently the standalonemmlibinternal assumes the max physical bits
to be 36 which is causing issues on v8 architectures.
Instead use the MAX_ALLOC_ADDRESS macro to determine the maximum
allowed address rather than recomputing it locally.
Signed-off-by: Girish Mahadevan <gmahadevan@nvidia.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Allow users to build OVMF then run QEMU by moving the build block above
the run block and removing the exit line.
Signed-off-by: Rebecca Cran <rebecca@quicinc.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
The IO Remapping Table, Platform Design Document, Revision E.e,
Sept 2022 (https://developer.arm.com/documentation/den0049/ee)
added flags in SMMUv3 node for validity of ID mappings for MSIs
related to control interrupts.
Therefore, update the IORT header file to:
- increment IORT table revision to 6
- add support for DeviceId valid flag
Signed-off-by: Swatisri Kantamsetti <swatisrik@nvidia.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Literally, the meaning of PcdDxeIplSwitchToLongMode is clear, indicating
whether need switch to long mode when loading DxeCore.
However, the comments in dec are confusing for the case where PEI core and
DXE core are both in 64-bit. This patch makes it clear.
PcdDxeIplSwitchToLongMode is true only when PEI core is 32-bit, and switch
to long mode to load 64-bit DXE core. In other cases, this PCD is false.
This also aligns with current usage in OvmfPkg.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Ray Ni <ray.ni@intel.com>
RedfishHostInterfaceDxe does not close protocol notify event in
event callback function. This could cause multiple version of
type 42 records issue if the protocol is installed more than once.
Close the event in callback function so we only create one type 42
record.
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: Abner Chang <abner.chang@amd.com>
As per the SCMI specification, section CLOCK_DESCRIBE_RATES mentions
that the value of num_rates_flags[11:0] in the response must be 3 if
the return format is the triplet. Due to the buggy firmware, this was
not noticed for long time. The firmware is now fixed resulting in
ClockDescribeRates() to fail with "Buffer Too Small" error as the
RequiredArraySize gets miscalculated as 72 instead of 24.
Fix the issue by reusing the logic for both the return format which
must work if num_rates_flags has correct value as expected from the
specification.
Cc: Girish Pathak <girish.pathak@arm.com>
Cc: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Tested-by: Pierre Gondois <pierre.gondois@arm.com>
Reported-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Tested-by: Sami Mujawar <sami.mujawar@arm.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4243
This patch enables Tdx measurement in OvmfPkgX64 with below changes:
1) CC_MEASUREMENT_ENABLE is introduced in OvmfPkgX64.dsc. This flag
indicates if Intel TDX measurement is enabled in OvmfPkgX64. Its
default value is FALSE.
2) Include TdTcg2Dxe in OvmfPkgX64 so that CC_MEASUREMENT_PROTOCOL
is installed in a Td-guest. TdTcg2Dxe is controlled by
TDX_MEASUREMENT_ENABLE because it is only valid when Intel TDX
measurement is enabled.
3) OvmfTpmLibs.dsc.inc and OvmfTpmSecurityStub.dsc.inc are updated
because DxeTpm2MeasureBootLib.inf and DxeTpmMeasurementLib.inf
should be included to support CC_MEASUREMENT_PROTOCOL.
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>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4243
MeasureFvImage once was implemented in PeilessStartupLib and it does
measurement and logging for Configuration FV (Cfv) image in one go,
using TpmMeasureAndLogData(). But it doesn't work in SEC.
This patch splits MeasureFvImage into 2 functions and implement them in
SecTdxHelperLib.
- TdxHelperMeasureCfvImage
- TdxHelperBuildGuidHobForTdxMeasurement
TdxHelperMeasureCfvImage measures the Cfv image and stores the hash value
in WorkArea. TdxHelperBuildGuidHobForTdxMeasurement builds GuidHob for the
measurement based on the hash value in WorkArea.
After these 2 functions are introduced, PeilessStartupLib should also be
updated:
- Call these 2 functions instead of the MeasureFvImage
- Delete the duplicated codes in PeilessStartupLib
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>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4243
MeasureHobList once was implemented in PeilessStartupLib and it does
measurement and logging for TdHob in one go, using TpmMeasureAndLogData().
But it doesn't work in SEC.
This patch splits MeasureHobList into 2 functions and implement them in
SecTdxHelperLib.
- TdxHelperMeasureTdHob
- TdxHelperBuildGuidHobForTdxMeasurement
TdxHelperMeasureTdHob measures the TdHob and stores the hash value in
WorkArea. TdxHelperBuildGuidHobForTdxMeasurement builds GuidHob for the
measurement based on the hash value in WorkArea.
After these 2 functions are introduced, PeilessStartupLib should also be
updated:
- Call these 2 functions instead of the MeasureHobList
- Delete the duplicated codes in PeilessStartupLib
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>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4243
TdxHelperLib provides below helper functions for a td-guest.
- TdxHelperProcessTdHob
- TdxHelperMeasureTdHob
- TdxHelperMeasureCfvImage
- TdxHelperBuildGuidHobForTdxMeasurement
SecTdxHelperLib is the SEC instance of TdxHelperLib. It implements 4
functions for tdx in SEC phase:
- TdxHelperProcessTdHob consumes TdHob to accept un-accepted memories.
Before the TdHob is consumed, it is first validated.
- TdxHelperMeasureTdHob measure/extend TdHob and store the measurement
value in workarea.
- TdxHelperMeasureCfvImage measure/extend the Configuration FV image and
store the measurement value in workarea.
- TdxHelperBuildGuidHobForTdxMeasurement builds GuidHob for tdx
measurement.
This patch implements the stubs of the functions. The actual
implementations are in the following patches. Because they are moved from
other files.
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>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4243
From the perspective of security any external input should be measured
and extended to some registers (TPM PCRs or TDX RTMR registers).
There are below 2 external input in a Td guest:
- TdHob
- Configuration FV (CFV)
TdHob contains the resource information passed from VMM, such as
unaccepted memory region. CFV contains the configurations, such as
secure boot variables.
TdHob and CFV should be measured and extended to RTMRs before they're
consumed. TdHob is consumed in the very early stage of boot process.
At that moment the memory service is not ready. Cfv is consumed in
PlatformPei to initialize the EmuVariableNvStore. To make the
implementation simple and clean, these 2 external input are measured
and extended to RTMRs in SEC phase. That is to say the tdx measurement
is only supported in SEC phase.
After the measurement the hash values are stored in WorkArea. Then after
the Hob service is available, these 2 measurement values are retrieved
and GuidHobs for these 2 tdx measurements are generated.
This patch defines the structure of TDX_MEASUREMENTS_DATA in
SEC_TDX_WORK_AREA to store above 2 tdx measurements. It can be extended
to store more tdx measurements if needed in the future.
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>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=4245
QEMU provides the following three files for guest to install the ACPI
tables:
- etc/acpi/rsdp
- etc/acpi/tables
- etc/table-loader
"etc/acpi/rsdp" and "etc/acpi/tables" are similar, they are only kept
separate because they have different allocation requirements in SeaBIOS.
Both of these fw_cfg files contain preformatted ACPI payload.
"etc/acpi/rsdp" contains only the RSDP table, while "etc/acpi/tables"
contains all other tables, concatenated. To be noted, the tables in these
two files have been filled in by qemu, but two kinds of fields are
incomplete: pointers to other tables and checksums (which depend on the
pointers).
"/etc/table-loader" is a linker/loader which provides the commands to
"patch" the tables in "etc/acpi/tables" and then install them. "Patch"
means to fill the pointers and compute the checksum.
From the security perspective these 3 files are the raw data downloaded
from qemu. They should be measured and extended before they're consumed.
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>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
According to the UEFI 2.10 Specification, the EFI_BOOT_SERVICES_TABLE
CreateEvent function has the following signature:
typedef
EFI_STATUS
(EFIAPI *EFI_CREATE_EVENT) (
IN UINT32 Type,
IN EFI_TPL NotifyTpl,
IN EFI_EVENT_NOTIFY NotifyFunction, OPTIONAL
IN VOID *NotifyContext, OPTIONAL
OUT EFI_EVENT *Event
);
Fix the prototype in UefiSpec.h to match, by labeling the NotifyFunction
and NotifyContext parameters as OPTIONAL.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Add a new parser for the Error Record Serialization Table.
The ERST table describes how an OS can save and retrieve
hardware error information to and from a persistent store.
Signed-off-by: Jeshua Smith <jeshuas@nvidia.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Currently DiscoverScsiDevice() returns a boolean which cannot
distinguish a "not found" situation from a real problem like
memory allocation failures.
This patch changes the return value to an EFI_STATUS so that when
memory allocation fails, it will return EFI_OUT_OF_RESOURCES.
Without this change, any FALSE returned by DiscoverScsiDevice()
will result in EFI_OUT_OF_RESOURCES being returned by
ScsiScanCreateDevice(), which will cause a while loop in
SCSIBusDriverBindingStart() to abort before other possible Puns in
the SCSI channel are scanned, which means good devices may not have
a chance to be discovered. If this good device is the boot device,
boot will fail.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Sivaparvathi chellaiah <sivaparvathic@ami.com>
Signed-off-by: Yuan Yu <yuanyu@google.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Since RvdPeCoffExtraActionLib has been deleted, remove lines referencing
it and the RealView Debugger from ArmVirtPkg.dsc.inc.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Acked-by: Bob Feng <bob.c.feng@intel.com>
The RealView Debugger is related to RVCT, which is no longer supported.
Given that, remove RvdPeCoffExtraActionLib and code from
RvdPeCoffExtraActionLib which prints lines for use with the RealView
Debugger.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Acked-by: Bob Feng <bob.c.feng@intel.com>
With the removal of RVCT support and the related Bin/CYGWIN_NT-5.1-i686
and Darwin-i386 directories, remove a leftover reference to
CYGWIN_NT-5.1-i686 from Scripts/PatchCheck.py.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Acked-by: Bob Feng <bob.c.feng@intel.com>
The enumeration in MdePkg/Include/Pi/PiDxeCis.h has a duplicated entry,
so the 8th position in the list doesn't count as index 7. The value
EfiGcdMemoryTypeUnaccepted will have when added before
EfiGcdMemoryTypeMaximum will be 6.
Cc: Min M Xu <min.m.xu@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Dionna Glaze <dionnaglaze@google.com>
Reviewed-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2928
commit 17bd834eb5 ("BaseTools: Factorize GCC flags")
makes GCC48_ALL_CC_FLAGS inherit from GCC_ALL_CC_FLAGS.
GCC_ALL_CC_FLAGS contains the '-Os' flag.
The latest flag in a command line overrides the previous
optimization option. This allows more specific build
configuration to override the inherited '-Os' flag.
If a build configuration includes GCC48_ALL_CC_FLAGS,
hard-coded '-Os' options are not necessary anymore.
Remove them.
Reported-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Add support for EFI_MP_SERVICES_PROTOCOL during the DXE phase under
AArch64.
PSCI_CPU_ON is called to power on the core, the supplied procedure is
executed and PSCI_CPU_OFF is called to power off the core.
Fixes contributed by Ard Biesheuvel.
Signed-off-by: Rebecca Cran <rebecca@quicinc.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Kun Qin <kun.qin@microsoft.com>
Instead of eagerly accepting all memory in PEI, only accept memory under
the 4GB address. This allows a loaded image to use the
MEMORY_ACCEPTANCE_PROTOCOL to disable the accept behavior and indicate
that it can interpret the memory type accordingly.
This classification is safe since ExitBootServices will accept and
reclassify the memory as conventional if the disable protocol is not
used.
Cc: Ard Biescheuvel <ardb@kernel.org>
Cc: "Min M. Xu" <min.m.xu@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Tom Lendacky <Thomas.Lendacky@amd.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Signed-off-by: Dionna Glaze <dionnaglaze@google.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
ArmVirtQemuKernel.dsc describes a firmware build that is loadable at
arbitrary address and can be invoked using the Linux/arm64 kernel boot
protocol. The early code deviates significantly from ArmVirtQemu, and so
it makes sense to cover this platform in CI even if it is not widely
used. This ensures that the relocatable PrePi and other components in
EmbeddedPkg don't regress on ARM as they are being updated for use on
TDVF.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
To increase the CI coverage, enable secure boot, TPM2 support and HTTPS
boot on ArmVirtQemu builds used in CI.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
In order to reduce the amount of code duplication, refactor the
PlatformBuild.py script that builds ArmVirtQemu.dsc into a reusable
PlatformBuildLib.py containing most of the bits and pieces, and a small
QemuBuild.py which is specific to the DSC in question.
Suggested-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
The initial ID map used by ArmVirtQemu only covers 2 MiB of NOR flash,
while the NOOPT build can be up to 3 MiB in size, resulting in a crash
if the unmapped 1 MiB is accessed before the real page tables are up.
So increate the initial flash mapping to 4 MiB.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
PrePi has a bare metal entry point, and so it is in charge of calling
the library constructors once the C runtime has been initialized
sufficiently.
However, we are now relying on a HOB to have been constructed by the
time the MMU code runs, and so the constructors should be run before
that.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4305
Based on whether the DER-encoded ContentInfo structure is present in
authenticated SetVariable payload or not, the SHA-256 OID can be
located at different places.
UEFI specification explicitly states the driver shall support both
cases, but the old code assumed ContentInfo was not present and
incorrectly rejected authenticated variable updates when it were
present.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Min Xu <min.m.xu@intel.com>
Signed-off-by: Jan Bobek <jbobek@nvidia.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Create PcdShellDefaultDelay to configure the default
delay the shell provides for the user at the start time
if the user wishes to cancel the execution of a potential
startup script.
The shell application already allows the user to override
the delay default value by specifying the -delay cmdline
argument. This however cannot be used when loading the
shell application using direct boot or when integrating
the shell into the platform firmware build.
Thus, a PCD can be easily configured by the developer
either at build time, or even at runtime.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Signed-off-by: Tomas Pilar <tomas@quicinc.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
In QEMU v5.1.0, the CPU hotplug register block misbehaves: the negotiation
protocol is (effectively) broken such that it suggests that switching from
the legacy interface to the modern interface works, but in reality the
switch never happens. The symptom has been witnessed when using TCG
acceleration; KVM seems to mask the issue. The issue persists with the
following (latest) stable QEMU releases: v5.2.0, v6.2.0, v7.2.0. Currently
there is no stable release that addresses the problem.
The QEMU bug confuses the Present and Possible counting in function
PlatformMaxCpuCountInitialization(), in
"OvmfPkg/Library/PlatformInitLib/Platform.c". OVMF ends up with Present=0
Possible=1. This in turn further confuses MpInitLib in UefiCpuPkg (hence
firmware-time multiprocessing will be broken). Worse, CPU hot(un)plug with
SMI will be summarily broken in OvmfPkg/CpuHotplugSmm, which (considering
the privilege level of SMM) is not that great.
Detect the issue in PlatformCpuCountBugCheck(), and print an error message
and *hang* if the issue is present.
Users willing to take risks can override the hang with the experimental
QEMU command line option
-fw_cfg name=opt/org.tianocore/X-Cpuhp-Bugcheck-Override,string=yes
(The "-fw_cfg" QEMU option itself is not experimental; its above argument,
as far it concerns the firmware, is experimental.)
The problem was originally reported by Ard [0]. We analyzed it at [1] and
[2]. A QEMU patch was sent at [3]; now merged as commit dab30fbef389
("acpi: cpuhp: fix guest-visible maximum access size to the legacy reg
block", 2023-01-08), to be included in QEMU v8.0.0.
[0] https://bugzilla.tianocore.org/show_bug.cgi?id=4234#c2
[1] https://bugzilla.tianocore.org/show_bug.cgi?id=4234#c3
[2] IO port write width clamping differs between TCG and KVM
http://mid.mail-archive.com/aaedee84-d3ed-a4f9-21e7-d221a28d1683@redhat.comhttps://lists.gnu.org/archive/html/qemu-devel/2023-01/msg00199.html
[3] acpi: cpuhp: fix guest-visible maximum access size to the legacy reg block
http://mid.mail-archive.com/20230104090138.214862-1-lersek@redhat.comhttps://lists.gnu.org/archive/html/qemu-devel/2023-01/msg00278.html
NOTE: PlatformInitLib is used in the following platform DSCs:
OvmfPkg/AmdSev/AmdSevX64.dsc
OvmfPkg/CloudHv/CloudHvX64.dsc
OvmfPkg/IntelTdx/IntelTdxX64.dsc
OvmfPkg/Microvm/MicrovmX64.dsc
OvmfPkg/OvmfPkgIa32.dsc
OvmfPkg/OvmfPkgIa32X64.dsc
OvmfPkg/OvmfPkgX64.dsc
but I can only test this change with the last three platforms, running on
QEMU.
Test results:
TCG QEMU OVMF override result
patched patched
--- ------- ------- -------- --------------------------------------
0 0 0 0 CPU counts OK (KVM masks the QEMU bug)
0 0 1 0 CPU counts OK (KVM masks the QEMU bug)
0 1 0 0 CPU counts OK (QEMU fix, but KVM masks
the QEMU bug anyway)
0 1 1 0 CPU counts OK (QEMU fix, but KVM masks
the QEMU bug anyway)
1 0 0 0 boot with broken CPU counts (original
QEMU bug)
1 0 1 0 broken CPU count caught (boot hangs)
1 0 1 1 broken CPU count caught, bug check
overridden, boot continues
1 1 0 0 CPU counts OK (QEMU fix)
1 1 1 0 CPU counts OK (QEMU fix)
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Michael Brown <mcb30@ipxe.org>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Oliver Steffen <osteffen@redhat.com>
Cc: Sebastien Boeuf <sebastien.boeuf@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=4250
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20230119110131.91923-3-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Hugely-appreciated-by: Michael Brown <mcb30@ipxe.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
QEMU for x86 has a nasty CPU hotplug bug of which the ramifications are
difficult to oversee, even though KVM acceleration seems to be
unaffected. This has been addressed in QEMU mainline, and will percolate
through the ecosystem at its usual pace. In the mean time, due to the
potential impact on production workloads, we will be updating OVMF to
abort the boot when it detects a QEMU build that is affected.
Tiancore's platform CI uses QEMU in TCG mode, and is therefore impacted
by this mitigation, unless its QEMU builds are updated. This has been
done for Ubuntu-GCC5, but Windows-VS2019 still uses a QEMU build that is
affected.
Aborting the boot upon detecting the QEMU issue will render all boot
tests carried out on Windows-VS2019 broken unless we implement the
'escape hatch' that enables proceed-at-your-own-risk mode, and permits
the boot to proceed even if the QEMU issue is detected.
So let's enable this for Windows-VS2019, and remove it again once it is
no longer needed.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Michael Brown <mcb30@ipxe.org>
Cc: Oliver Steffen <osteffen@redhat.com>
Cc: Michael Kubacki <michael.kubacki@microsoft.com>
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=4250
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Message-Id: <20230119134302.1524569-1-ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Acked-by: Jiewen Yao <Jiewen.yao@Intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
In commit c673216f53 a new input parameter is added in FfsFindSectionData.
That change breaks the build of ArmVirtPkg. In this patch
FfsFindSectionData is added back. It calls FfsFindSectionDataWithHook with
a NULL hook.
Signed-off-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Commit c673216f53 introduces FFS_CHECK_SECTION_HOOK and add it as the
second input parameter in FfsFindSectionData. This change breaks the build
of ArmVirtPkg. To fix this issue, the new version of FfsFindSectionData
is renamed as FfsFindSectionDataWithHook in this patch. In the following
patch the original FfsFindSectionData will be added back.
FfsFindSectionData is renamed as FfsFindSectionDataWithHook. Accordingly
PeilessStartupLib in OvmfPkg should be updated as well. To prevent the
build from being broken, the changes in OvmfPkg are in this patch.
Signed-off-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Add IpmiCommandLib to MdeModulePkg. This header file is
copied from edk2-platforms/Features/Intel/OutOfBandManagement/
IpmiFeaturePkg\Include\Library. Having this header file in
edk2 to avoid the dependence of edk2 module with edk2-platfrom.
The NULL instance of IpmiCommandLib under MdeModulePkg has
to be implemented for the same reason.
IpmiCommandLib.h in edk2-platforms should be removed once
this patch set is merged. Expect no impacts on edk2-platforms
because MdeModulePkg is referred in INF file by all edk2
modules under edk2-platforms that use IpmiCommandLib.
Signed-off-by: Abner Chang <abner.chang@amd.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Nickle Wang <nicklew@nvidia.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Cc: Isaac Oram <isaac.w.oram@intel.com>
Cc: Nate DeSimone <nathaniel.l.desimone@intel.com>
Reviewed-by: Isaac Oram <isaac.w.oram@intel.com>
Reviewed-by: Igor Kulchytskyy <igork@ami.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
According to TCG PC Client PFP spec 0021 Section 2.4.4.2 EFI boot variable
should be measured and extended to PCR[1], not PCR[5]. This patch is
proposed to fix this error.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4152
In current DXE FV there are 100+ drivers. Some of the drivers are not
used in Td guest. (Such as USB support drivers, network related drivers,
etc).
From the security perspective if a driver is not used, we'd should prevent
it from being loaded / started. There are 2 benefits:
1. Reduce the attack surface
2. Improve the boot performance
So we separate DXEFV into 2 FVs: DXEFV and NCCFV. All the drivers which
are not needed by a Confidential Computing guest are moved from DXEFV
to NCCFV.
The following patch will find NCCFV for non-cc guest and build FVHob
so that NCCFV drivers can be loaded / started in DXE phase.
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
In smbiosview command in shell, below are the fields of SMBIOS
Type38 table which can be displayed in formatted manner.
1. Base Address
1. IPMI Specification Version.
2. NV Storage Device Address.
Base Address:
As per spec, the value in Base Address field of SMBIOS type38 table
should be right shifted by 1 if the interface type is SSIF.
IPMI Specification Version:
If the value in IPMI Specification Version field is 15H,
it should be displayed 1.5.
NV Storage Device Address:
If the value in NV Storage Device Address field is 0xFF,
it should be displayed as "No storage device is Present".
Cc: Vasudevan Sambandan <vasudevans@ami.com>
Cc: Sundaresan Selvaraj <sundaresans@ami.com>
Cc: Gayathri Thunuguntla <gayathrit@ami.com>
Signed-off-by: Prakash K <prakashk@ami.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Remove BaseTools/Bin/gcc_*_ext_dep.yaml to stop downloading gcc from
external locations; use the gcc provided by the container image instead.
The container image sets the variable GCC5_*_PREFIX accordingly.
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Chris Fernald <chfernal@microsoft.com>
All ext_dep.yml files for gcc have been removed and gcc is expected to
be installed on the system (GCC5_*_PREFIX may indicate the location).
No need to adjust the toolchain scopes for Linux builds anymore.
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Chris Fernald <chfernal@microsoft.com>
Run the Linux jobs of the OvmfPkg platform CI inside a container,
in the same way the general CI does now. Make use of the default image
specified in the defaults.yml template.
Do not run apt-get in CI jobs to install qemu and gcc dependencies.
Assume the container image provides these.
Use Python from the container image, do not download at runtime.
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Acked-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Chris Fernald <chfernal@microsoft.com>
Run the Linux jobs of the EmulatorPkg platform CI inside a container,
in the same way the general CI does now. Make use of the default image
specified in the defaults.yml template.
Use Python from the container image, do not download at runtime.
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Chris Fernald <chfernal@microsoft.com>
Run the Linux jobs of the ArmVirtPkg platform CI inside a container,
in the same way the general CI does now. Make use of the default image
specified in the defaults.yml template.
Do not run apt-get in CI jobs to install qemu and gcc dependencies.
Assume the container image provides these.
Use Python from the container image, do not download at runtime.
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Chris Fernald <chfernal@microsoft.com>
Run all Linux based jobs in a container, using a custom Fedora 35 image
(gcc 11). The image URL specified in the defaults.yml template, so that
all CI jobs can use it. The image is hosted on ghcr.io and the
Dockerfiles are here: https://github.com/tianocore/containers The
version numbers of gcc, iasl, and nasm are pinned to avoid unintended
upgrades during image rebuild.
Do not run apt-get in CI jobs to install qemu and gcc dependencies.
Assume the container image provides these.
Use Python from the container image, do not download at runtime.
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Chris Fernald <chfernal@microsoft.com>
Add a parameter of the pr-gate-build-job template to specify a
container image URL. If the value is not '' (default), then the
jobs will be run inside a container based on that image.
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Chris Fernald <chfernal@microsoft.com>
Without adding ~/.local/bin to PATH, `pip install` will throw
an error when running inside a container.
Containers will be introduced to the CI in the following commits.
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Chris Fernald <chfernal@microsoft.com>
Use the default Python version from the defaults template
(.azurepipelines/templates/defaults.yml) in the Windows and
Linux CI jobs.
Previous changes to the CI job templates make it necessary
to specify a version number, if Python shall be pulled
at CI runtime.
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Acked-by: Jiewen Yao <jiewen.yao@intel.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Chris Fernald <chfernal@microsoft.com>
Use the default Python version from the defaults template
(.azurepipelines/templates/defaults.yml) in the Windows and
Linux CI jobs.
Previous changes to the CI job templates make it necessary
to specify a version number, if Python shall be pulled
at CI runtime.
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Chris Fernald <chfernal@microsoft.com>
Use the default Python version from the defaults template
(.azurepipelines/templates/defaults.yml) in the Windows and
Linux CI jobs.
Previous changes to the CI job templates make it necessary
to specify a version number, if Python shall be pulled
at CI runtime.
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Chris Fernald <chfernal@microsoft.com>
Add a new parameter "usePythonVersion" to the CI job templates.
This makes it possible to specify the version of Python to use.
The default value is '', in which case Python will not be downloaded
at runtime and the one provided by the VM/container image will be used.
Additionally, add a template .azurepipelines/templates/defaults.yml,
from which the default Pyhton version string can be obtained.
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Chris Fernald <chfernal@microsoft.com>
First handle the cases which do not need know the value of
PlatformInfoHob->LowMemory (microvm and cloudhv). Then call
PlatformGetSystemMemorySizeBelow4gb() to get LowMemory. Finally handle
the cases (q35 and pc) which need to look at LowMemory,
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Add PlatformReservationConflictCB() callback function for use with
PlatformScanE820(). It checks whenever the 64bit PCI MMIO window
overlaps with a reservation from qemu. If so move down the MMIO window
to resolve the conflict.
Write any actions done (moving mmio window) to the firmware log with
INFO loglevel.
This happens on (virtual) AMD machines with 1TB address space,
because the AMD IOMMU uses an address window just below 1TB.
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=4251
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Add PlatformAddHobCB() callback function for use with
PlatformScanE820(). It adds HOBs for high memory and reservations (low
memory is handled elsewhere because there are some special cases to
consider). This replaces calls to PlatformScanOrAdd64BitE820Ram() with
AddHighHobs = TRUE.
Write any actions done (adding HOBs, skip unknown types) to the firmware
log with INFO loglevel.
Also remove PlatformScanOrAdd64BitE820Ram() which is not used any more.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Add PlatformGetLowMemoryCB() callback function for use with
PlatformScanE820(). It stores the low memory size in
PlatformInfoHob->LowMemory. This replaces calls to
PlatformScanOrAdd64BitE820Ram() with non-NULL LowMemory.
Write any actions done (setting LowMemory) to the firmware log
with INFO loglevel.
Also change PlatformGetSystemMemorySizeBelow4gb() to likewise set
PlatformInfoHob->LowMemory instead of returning the value. Update
all Callers to the new convention.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
First step replacing the PlatformScanOrAdd64BitE820Ram() function.
Add a PlatformScanE820() function which loops over the e280 entries
from FwCfg and calls a callback for each of them.
Add a GetFirstNonAddressCB() function which will store the first free
address (right after the last RAM block) in
PlatformInfoHob->FirstNonAddress. This replaces calls to
PlatformScanOrAdd64BitE820Ram() with non-NULL MaxAddress.
Write any actions done (setting FirstNonAddress) to the firmware log
with INFO loglevel.
Also drop local FirstNonAddress variables and use
PlatformInfoHob->FirstNonAddress instead everywhere.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Even though the presence of the 'packed' pragma should be a strong hint
that the misaligned placement of a GUID in a struct is intentional,
recent Clang versions will object nonetheless, and break the build due
to the presence of such GUIDs in the FPDT ACPI tables.
This is obviously not something we can fix in the code, so let's just
suppress the warning/error instead.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Recent GCC for ARM will complain when selecting the hard float ABI
without specifying the FPU implementation, even when just running the
preprocessor.
This all happens under the hood, and we never bothered in the past,
given that we don't emit floating point code anyway. However, to placate
newer compilers, make it explicit that the floating point ABI is always the
softfloat one, by moving the -msoft-float compiler option to
PLATFORM_FLAGS.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
ARCHCC_FLAGS and ARCHASM_FLAGS no longer serve a useful purpose so drop
all the definitions and references.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
The global GCC_PP_FLAGS tools_def variable now contains a reference to
OpenSBI specific C preprocessor variables, which means they are added to
the command line on every architecture, not just RISC-V.
This does not currently result in any issues, but it is a bit sloppy so
let's clean this up. Given that the GCC_PP_FLAGS definition appears
twice, drop the one that carries the OpenSBI reference, and move that
reference to a new RISC-V specific variable.
Acked-by: Abner Chang <abner.chang@amd.com>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
EDKII build system supports OptionROM generation if particular PCI_*
defines are present in the module INF file:
```
[Defines]
...
PCI_VENDOR_ID = <...>
PCI_DEVICE_ID = <...>
PCI_CLASS_CODE = <...>
PCI_REVISION = <...>
```
Although after the commit d372ab585a
("BaseTools/Conf: Fix Dynamic-Library-File template") it is no longer
possible.
The build system fails with the error:
```
Cyclic dependency detected while generating rule for
"<...>/DEBUG/<...>.efi" file
```
Remove "$(DEBUG_DIR)(+)$(MODULE_NAME).efi" from the 'dll' output files
to fix the cyclic dependency.
Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Commit 789a723285 reclassified the NOR flash region as EFI_MEMORY_WC
in the OS visible EFI memory map, and dropped the explicit aligned
CopyMem() implementation, in the assumption that EFI_MEMORY_WC will be
honored by the OS, and that the region will be mapped in a way that
tolerates misaligned accesseses. However, Linux today uses device
attributes for all EFI MMIO regions, in spite of the memory type
attributes, and so using misaligned accesses is never safe.
So instead, switch to the generic CopyMem() implementation entirely,
just like we already did for VariableRuntimeDxe.
Fixes: 789a723285 ("OvmfPkg/VirtNorFlashDxe: use EFI_MEMORY_WC and drop AlignedCopyMem()")
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Switching from the ArmPlatformPkg/NorFlashDxe driver to the
OvmfPkg/VirtNorFlashDxe driver had the side effect that flash address
space got registered as EFI_MEMORY_WC instead of EFI_MEMORY_UC.
That confuses the linux kernel's numa code, seems this makes kernel
consider the flash being node memory. "lsmem" changes from ...
RANGE SIZE STATE REMOVABLE BLOCK
0x0000000040000000-0x000000013fffffff 4G online yes 8-39
... to ...
RANGE SIZE STATE REMOVABLE BLOCK
0x0000000000000000-0x0000000007ffffff 128M online yes 0
0x0000000040000000-0x000000013fffffff 4G online yes 8-39
... and in the kernel log got new error lines:
NUMA: Warning: invalid memblk node 512 [mem 0x0000000004000000-0x0000000007ffffff]
NUMA: Faking a node at [mem 0x0000000004000000-0x000000013fffffff]
Changing the attributes back to EFI_MEMORY_UC fixes this.
Fixes: b92298af82 ("ArmVirtPkg/ArmVirtQemu: migrate to OVMF's VirtNorFlashDxe")
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
In commit 49edde1523 ("OvmfPkg/PlatformPei: set 32-bit UC area at
PciBase / PciExBarBase (pc/q35)", 2019-06-03), I forgot to update the
comment. Do it now.
Fixes: 49edde1523
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
The early ID map used by ArmVirtQemu uses ASID scoped non-global
mappings, as this allows us to switch to the permanent ID map seamlessly
without the need for explicit TLB maintenance.
However, this triggers a known erratum on ThunderX, which does not
tolerate non-global mappings that are executable at EL1, as this appears
to result in I-cache corruption. (Linux disables the KPTI based Meltdown
mitigation on ThunderX for the same reason)
So work around this, by detecting the CPU implementor and part number,
and proceeding without the early ID map if a ThunderX CPU is detected.
Note that this requires the C code to be built with strict alignment
again, as we may end up executing it with the MMU and caches off.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: dann frazier <dann.frazier@canonical.com>
Now that we build the early code without strict alignment and without
suppressing the use of SIMD registers, ensure that the VFP unit is on
before entering C code.
While at it, simplyify the mov_i macro, which is only used for 32-bit
quantities.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: dann frazier <dann.frazier@canonical.com>
Linux's cpu DT bindings call out arm,armv8 while the code previously
used arm,arm-v8, add second entry to support the arm,armv8 case.
Cc: Sami Mujawar <sami.mujawar@arm.com>
Fixes: e366a41ef0 ("DynamicTablesPkg: FdtHwInfoParser: Add GICC parser")
Signed-off-by: Moritz Fischer <moritzf@google.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Add myself as a reviewer for OVMF/Confidential Computing patches.
Remove Brijesh while at it, since he is no longer at AMD, and the email
is no longer valid.
Suggested-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Michael Roth <michael.roth@amd.com>
Acked-by: Jiewen Yao <jiewen.yao@intel.com>
I suggest that Gerd be notified about all UefiCpuPkg patches, so he may
take a quick look at, or (by his preference) even test, the proposed
change, in a genuine QEMU/KVM environment.
Assuming this patch is accepted -- subsequently, please *wait* for Gerd's
approval on UefiCpuPkg patches, before merging them.
Notes:
- It's perfectly fine for a reviewer to give an A-b just so the review
process be unblocked, if they don't have anything to add, or don't have
time to review or test in detail. The point is that someone outside of
Intel should *consistently get a chance* to raise concerns about
UefiCpuPkg patches before they are merged.
- My A-b's and R-b's on UefiCpuPkg patches were never supposed to be
"sufficient", only "necessary", for merging. The intent is the same
here, with Gerd's designation as a reviewer.
Cc: Andrew Fish <afish@apple.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20230103160539.87830-1-lersek@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Similarly to the "cadence" mentioned in commit d272449d9e ("OvmfPkg:
raise DXEFV size to 11 MB", 2018-05-29), it's been ~1.75 years since
commit 5e75c4d1fe ("OvmfPkg: raise DXEFV size to 12 MB", 2020-03-11),
and we've outgrown DXEFV again (with NOOPT builds). Increase the DXEFV
size to 13MB now.
Do not modify all platform FDF files under OvmfPkg. "BhyveX64.fdf" is
still at 11MB, "OvmfXen.fdf" at 10MB. The "AmdSevX64.fdf",
"CloudHvX64.fdf", "IntelTdxX64.fdf" and "MicrovmX64.fdf" flash devices
could be modified similarly (from 12MB to 13MB), but I don't use or build
those platforms.
Tested on:
- 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:
- 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
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien@xen.org>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Peter Grehan <grehan@freebsd.org>
Cc: Rebecca Cran <rebecca@bsdio.com>
Cc: Sebastien Boeuf <sebastien.boeuf@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4236
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Per my bisection: nasm broke the parsing of the "--" end-of-options
delimiter in commit 55568c1193df ("nasm: scan the command line twice",
2016-10-03), part of the nasm-2.13 release. The parsing remains broken in
at least nasm-2.15.03. The (invalid) error message is: "more than one
input file specified". I've filed the following ticket for upstream nasm
(and ndisasm): <https://bugzilla.nasm.us/show_bug.cgi?id=3392829>.
Since the delimiter is not necessary in practice (due to $STEM being
"VbeShim", i.e., not starting with a hyphen), simply remove the delimiter.
Tested by enabling DEBUG in "VbeShim.asm", running the script, building
OVMF, booting Windows 7, and checking the firmware log (debug console).
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>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3876
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Force resetting the port by clearing the USB_PORT_STAT_C_RESET bit in
PortChangeStatus when XhcPollPortStatusChange fails
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
For Windows add below tool for code coverage
1. OpenCppCoverage: parsing pdb file to generate coverage
data
2. pycobertura: show up html format data for coverage data
For Linux add below tool for code coverage
1. lcov: parsing gcda gcno file to generate coverage data
2. lcov-cobertura: convert coverage data to cobertura format
3. pycobertura: show up html format data for coverage data
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Signed-off-by: Gua Guo <gua.guo@intel.com>
When setting new page table pool to RO, only disable/enable WP when
Cr0.WP has been set to 1 to fix potential PF caused by b822be1a20
(UefiCpuPkg/PiSmmCpuDxeSmm: Introduce page table pool mechanism).
With previous code, if someone want to modify the page table and
Cr0.WP has been cleared before modify page table, Cr0.WP may be set
to 1 again since new pool may be generated during this process
Then PF fault may happens.
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>
Prior to this change, deps were not generated for Arm and AARCH64
libraries when MODULE_TYPE was BASE, SEC, PEI_CORE, or PIEM. That
resulted in bad incremental builds.
Signed-off-by: Jake Garver <jake@nvidia.com>
Reviewed-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
When checking the version in DevicePath's Makefile, use BUILD_CC instead
of assuming "gcc". BUILD_CC is set in header.makefile and is the
compiler that will actually be used to build DevicePath. It defaults to
"gcc", but may be overridden.
Signed-off-by: Jake Garver <jake@nvidia.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
UEFI requires us to support nested interrupts, but provides no way for
an interrupt handler to call RestoreTPL() without implicitly
re-enabling interrupts. In a virtual machine, it is possible for a
large burst of interrupts to arrive. We must prevent such a burst
from leading to stack underrun, while continuing to allow nested
interrupts to occur.
This can be achieved by allowing, when provably safe to do so, an
inner interrupt handler to return from the interrupt without restoring
the TPL and with interrupts remaining disabled after IRET, with the
deferred call to RestoreTPL() then being issued from the outer
interrupt handler. This is necessarily messy and involves direct
manipulation of the interrupt stack frame, and so should not be
implemented as open-coded logic within each interrupt handler.
Add the Nested Interrupt TPL Library (NestedInterruptTplLib) to
provide helper functions that can be used by nested interrupt handlers
in place of RaiseTPL()/RestoreTPL().
Example call tree for a timer interrupt occurring at TPL_APPLICATION
with a nested timer interrupt that makes its own call to RestoreTPL():
outer TimerInterruptHandler()
InterruptedTPL == TPL_APPLICATION
...
IsrState->InProgressRestoreTPL = TPL_APPLICATION;
gBS->RestoreTPL (TPL_APPLICATION);
EnableInterrupts();
dispatch a TPL_CALLBACK event
gEfiCurrentTpl = TPL_CALLBACK;
nested timer interrupt occurs
inner TimerInterruptHandler()
InterruptedTPL == TPL_CALLBACK
...
IsrState->InProgressRestoreTPL = TPL_CALLBACK;
gBS->RestoreTPL (TPL_CALLBACK);
EnableInterrupts();
DisableInterrupts();
IsrState->InProgressRestoreTPL = TPL_APPLICATION;
IRET re-enables interrupts
... finish dispatching TPL_CALLBACK events ...
gEfiCurrentTpl = TPL_APPLICATION;
DisableInterrupts();
IsrState->InProgressRestoreTPL = 0;
sees IsrState->DeferredRestoreTPL == FALSE and returns
IRET re-enables interrupts
Example call tree for a timer interrupt occurring at TPL_APPLICATION
with a nested timer interrupt that defers its call to RestoreTPL() to
the outer instance of the interrupt handler:
outer TimerInterruptHandler()
InterruptedTPL == TPL_APPLICATION
...
IsrState->InProgressRestoreTPL = TPL_APPLICATION;
gBS->RestoreTPL (TPL_APPLICATION);
EnableInterrupts();
dispatch a TPL_CALLBACK event
... finish dispatching TPL_CALLBACK events ...
gEfiCurrentTpl = TPL_APPLICATION;
nested timer interrupt occurs
inner TimerInterruptHandler()
InterruptedTPL == TPL_APPLICATION;
...
sees InterruptedTPL == IsrState->InProgressRestoreTPL
IsrState->DeferredRestoreTPL = TRUE;
DisableInterruptsOnIret();
IRET returns without re-enabling interrupts
DisableInterrupts();
IsrState->InProgressRestoreTPL = 0;
sees IsrState->DeferredRestoreTPL == TRUE and loops
IsrState->InProgressRestoreTPL = TPL_APPLICATION;
gBS->RestoreTPL (TPL_APPLICATION); <-- deferred call
EnableInterrupts();
DisableInterrupts();
IsrState->InProgressRestoreTPL = 0;
sees IsrState->DeferredRestoreTPL == FALSE and returns
IRET re-enables interrupts
Cc: Paolo Bonzini <pbonzini@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4162
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Deferring the EOI until after the call to RestoreTPL() means that any
callbacks invoked by RestoreTPL() will run with timer interrupt
delivery disabled. If any such callbacks themselves rely on timers to
implement timeout loops, then the callbacks will get stuck in an
infinite loop from which the system will never recover.
This reverts commit 239b50a86 ("OvmfPkg: End timer interrupt later to
avoid stack overflow under load").
Cc: Paolo Bonzini <pbonzini@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4162
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
qemu uses the etc/e820 fw_cfg file not only for memory, but
also for reservations. Handle reservations by adding resource
descriptor hobs for them.
A typical qemu configuration has a small reservation between
lapic and flash:
# sudo cat /proc/iomem
[ ... ]
fee00000-fee00fff : Local APIC
feffc000-feffffff : Reserved <= HERE
ffc00000-ffffffff : Reserved
[ ... ]
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
The Hii form is named "MainFormState" and the EFI variable is named
"PlatformConfig". Take into account the different names.
Fixes: aefcc91805 ("OvmfPkg/PlatformDxe: Handle all requests in ExtractConfig and RouteConfig")
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
BDS module was moved from DXEFV to newly created BDSFV recently.
Non-universal UEFI payload doesn't support multiple FV, so it failed
to boot since BDS module could not be found.
This patch add BDS back to DXEFV when UNIVERSAL_PAYLOAD is not set.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Sean Rhodes <sean@starlabs.systems>
Cc: James Lu <james.lu@intel.com>
Cc: Gua Guo <gua.guo@intel.com>
Signed-off-by: Guo Dong <guo.dong@intel.com>
Reviewed-by: James Lu <james.lu@intel.com>
Reviewed-by: Gua Guo <gua.guo@intel.com>
PcdConfidentialComputingGuestAttr can be used to check the cc guest
type, including td-guest or sev-guest. CcProbe() can do the same
thing but CcProbeLib should be included in the dsc which uses
AcpiPlatformDxe. The difference between PcdConfidentialComputingGuestAttr
and CcProbe() is that PcdConfidentialComputingGuestAttr cannot be used
in multi-processor scenario but CcProbe() can. But there is no such
issue in AcpiPlatformDxe.
So we use PcdConfidentialComputingGuestAttr instead of CcProbeLib so that
it is simpler.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
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>
Signed-off-by: Min Xu <min.m.xu@intel.com>
Fixes problems due to code assuming it runs with frame pointers and thus
updates rbp / ebp registers when switching stacks.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Tested-by: Liming Gao <gaoliming@byosoft.com.cn>
Simplify the code to set memory used by smm page table as RO.
Since memory used by smm page table are in PageTablePool list,
we only need to set all PageTablePool as ReadOnly in smm page
table itself. Also, we only need to flush tlb once after
setting all page table pool as Read Only.
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>
Remove SmmCpuFeaturesAllocatePageTableMemory in this headfile.
This API is not used by PiSmmCpuDxeSmm driver any more. Also
no other files use this API.
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>
Introduce page table pool mechanism for smm page table to simplify
page table memory management and protection. This mechanism has been
used in DxeIpl. The basic idea is to allocate a bunch of continuous
pages of memory in advance, and all future page tables consumption
will happen in those pool instead of system memory.
Since we have centralized page tables, we only need to mark all page
table pools as RO, instead of searching page table memory layer by
layer in smm page table. Once current page table pool has been used
up, another memory pool will be allocated and the new pool will also
be set as RO if current page table memory has been marked as RO.
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>
Copy the function BuildPlatformInfoHob() from OvmfPkg/PlatformPei.
QemuFwCfgLib expect this HOB to be present, or fails to do anything.
InternalQemuFwCfgIsAvailable() from QemuFwCfgPeiLib module will not
check if the HOB is actually present for example and try to use a NULL
pointer.
Fixes: cda98df162 ("OvmfPkg/QemuFwCfgLib: remove mQemuFwCfgSupported + mQemuFwCfgDmaSupported")
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Jiewen Yao <jiewen.yao@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4172
TDVF once accepts memory only by BSP. To improve the boot performance
this patch introduce the multi-core accpet memory. Multi-core means
BSP and APs work together to accept memory.
TDVF leverages mailbox to wake up APs. It is not enabled in MpInitLib
(Which requires SIPI). So multi-core accept memory cannot leverages
MpInitLib to coordinate BSP and APs to work together.
So TDVF split the accept memory into 2 phases.
- AcceptMemoryForAPsStack:
BSP accepts a small piece of memory which is then used by APs to setup
stack. We assign a 16KB stack for each AP. So a td-guest with 256 vCPU
requires 255*16KB = 4080KB.
- AcceptMemory:
After above small piece of memory is accepted, BSP commands APs to
accept memory by sending AcceptPages command in td-mailbox. Together
with the command and accpet-function, the APsStack address is send
as well. APs then set the stack and jump to accept-function to accept
memory.
AcceptMemoryForAPsStack accepts as small memory as possible and then jump
to AcceptMemory. It fully takes advantage of BSP/APs to work together.
After accept memory is done, the memory region for APsStack is not used
anymore. It can be used as other private memory. Because accept-memory
is in the very beginning of boot process and it will not impact other
phases.
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4172
TdxMailboxLib is designed only for TDX guest which arch is X64. This
patch set the VALID_ARCHITECTURES of TdxMailboxLib as X64.
Because in the following patches TdxMailboxLib will be included in
PlatformInitLib. While PlatformInitLib is imported by some X64 platforms
(for example AmdSevX64.dsc). So we need a NULL instance of TdxMailboxLib
which VALID_ARCHITECTURES is X64 as well. Based on this consideration
we design TdxMailboxLibNull.
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
- Fix typos of "disable".
- Fix typos of "performance".
- Fix missing spaces.
- Use comma instead of period when the sentence continues on the next
line.
- Fix typo of "PERF_CORE_LOAD_IMAGE".
Signed-off-by: Rebecca Cran <rebecca@quicinc.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Fix typo of EFI_INVALID_PARAMETER in Protocol/UsbIo.h by adding a
missing 'R'.
Signed-off-by: Rebecca Cran <rebecca@quicinc.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
On some platforms, including Sky Lake and Kaby Lake, the PSIV (Protocol
Speed ID Value) indices are shared between Protocol Speed ID DWORD' in
the extended capabilities registers for both USB2 (Full Speed) and USB3
(Super Speed).
An example can be found below:
XhcCheckUsbPortSpeedUsedPsic: checking for USB2 ext caps
XhciPsivGetPsid: found 3 PSID entries
XhciPsivGetPsid: looking for port speed 1
XhciPsivGetPsid: PSIV 1 PSIE 2 PLT 0 PSIM 12
XhciPsivGetPsid: PSIV 2 PSIE 1 PLT 0 PSIM 1500
XhciPsivGetPsid: PSIV 3 PSIE 2 PLT 0 PSIM 480
XhcCheckUsbPortSpeedUsedPsic: checking for USB3 ext caps
XhciPsivGetPsid: found 3 PSID entries
XhciPsivGetPsid: looking for port speed 1
XhciPsivGetPsid: PSIV 1 PSIE 3 PLT 0 PSIM 5
XhciPsivGetPsid: PSIV 2 PSIE 3 PLT 0 PSIM 10
XhciPsivGetPsid: PSIV 34 PSIE 2 PLT 0 PSIM 1248
The result is edk2 detecting USB2 devices as USB3 devices, which
consequently causes enumeration to fail.
To avoid incorrect detection, check the Compatible Port Offset to find
the starting Port of Root Hubs that support the protocol.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
PSID matching relies on comparing the PSIV against the PortSpeed
value. This patch stops edk2 from checking for a PSIV of 0, as it
is not valid; this reduces the number of register access by
approximately 6 per second.
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
During the finalization of Mp initialization before booting into the OS,
depending on whether Mwait is supported or not, AsmRelocateApLoop
places Aps in MWAIT-loop or HLT-loop.
Since paging is necessary for long mode, the original implementation of
moving APs to 32-bit was to disable paging to ensure that the booting
does not crash.
The current modification creates a page table in reserved memory,
avoiding switching modes and reclaiming memory by OS. This modification
is only for 64 bit mode.
More specifically, we keep the AMD logic as the original code flow,
extract and update the Intel-related code, where the APs would stay
in 64-bit, and run in a Mwait or Hlt loop until the OS wake them up.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
AsmRelocateApLoop is replicated for future Intel Logic Extraction,
further brings AP into 64-bit, and enables paging.
Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Add condition to return success if mUartCount is greater
than zero in SerialPortInitialize() to avoid filling mUartInfo
with the same hob data when SerialPortInitialize() is called
multiple times. Also add proper conditions in SerialPortRead
function to read the data properly from multiple UART's.
Cc: Guo Dong <guo.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: James Lu <james.lu@intel.com>
Reviewed-by: Gua Guo <gua.guo@intel.com>
Signed-off-by: Kavya <k.kavyax.sravanthi@intel.com>
For some use cases, Redfish host interface table relies on
the certain EFI protocols installation at the driver connection.
Redfish host interface DXE driver is not able to build the
SMBIOS type 42h record at driver entry point. This patch adds
the mechanism in Redfish host interface DXE driver to listen
to EFI protocol installed by platform library that indicates
the necessary information is ready for building SMBIOS 42h
record.
Signed-off-by: Abner Chang <abner.chang@amd.com>
Cc: Nickle Wang <nicklew@nvidia.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Reviewed-by: Nickle Wang <nicklew@nvidia.com>
In the commit 4f173db8b4 "OvmfPkg/PlatformInitLib: Add functions for
EmuVariableNvStore", it introduced a PlatformValidateNvVarStore() function
for checking the integrity of NvVarStore.
In some cases when the VariableHeader->StartId is VARIABLE_DATA, the
VariableHeader->State is not just one of the four primary states:
VAR_IN_DELETED_TRANSITION, VAR_DELETED, VAR_HEADER_VALID_ONLY, VAR_ADDED.
The state may combined two or three states, e.g.
0x3C = (VAR_IN_DELETED_TRANSITION & VAR_ADDED) & VAR_DELETED
or
0x3D = VAR_ADDED & VAR_DELETED
When the variable store has those variables, system booting/rebooting will
hangs in a ASSERT:
NvVarStore Variable header State was invalid.
ASSERT
/mnt/working/source_code-git/edk2/OvmfPkg/Library/PlatformInitLib/Platform.c(819):
((BOOLEAN)(0==1))
Adding more log to UpdateVariable() and PlatformValidateNvVarStore(), we
saw some variables which have 0x3C or 0x3D state in store.
e.g.
UpdateVariable(), VariableName=BootOrder
L1871, State=0000003F <-- VAR_ADDED
State &= VAR_DELETED=0000003D
FlushHobVariableToFlash(), VariableName=BootOrder
...
UpdateVariable(), VariableName=InitialAttemptOrder
L1977, State=0000003F
State &= VAR_IN_DELETED_TRANSITION=0000003E
L2376, State=0000003E
State &= VAR_DELETED=0000003C
FlushHobVariableToFlash(), VariableName=InitialAttemptOrder
...
UpdateVariable(), VariableName=ConIn
L1977, State=0000003F
State &= VAR_IN_DELETED_TRANSITION=0000003E
L2376, State=0000003E
State &= VAR_DELETED=0000003C
FlushHobVariableToFlash(), VariableName=ConIn
...
So, only allowing the four primary states is not enough. This patch changes
the falid states list (Follow Jiewen Yao's suggestion):
1. VAR_HEADER_VALID_ONLY (0x7F)
- Header added (*)
2. VAR_ADDED (0x3F)
- Header + data added
3. VAR_ADDED & VAR_IN_DELETED_TRANSITION (0x3E)
- marked as deleted, but still valid, before new data is added. (*)
4. VAR_ADDED & VAR_IN_DELETED_TRANSITION & VAR_DELETED (0x3C)
- deleted, after new data is added.
5. VAR_ADDED & VAR_DELETED (0x3D)
- deleted directly, without new data.
(*) means to support surprise shutdown.
And removed (VAR_IN_DELETED_TRANSITION) and (VAR_DELETED) because they are
invalid states.
v2:
Follow Jiewen Yao's suggestion to add the following valid states:
VAR_ADDED & VAR_DELETED (0x3D)
VAR_ADDED & VAR_IN_DELETED_TRANSITION (0x3E)
VAR_ADDED & VAR_IN_DELETED_TRANSITION & VAR_DELETED (0x3C)
and removed the following invalid states:
VAR_IN_DELETED_TRANSITION
VAR_DELETED
Signed-off-by: Chun-Yi Lee <jlee@suse.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
The following PCDs have no value in UefiPayloadPkg.dsc
and they can not pass the Ecc tool check, so assign
the default values the same as they are in *.dec file.
1. gEfiMdeModulePkgTokenSpaceGuid.PcdAriSupport
2. gEfiMdeModulePkgTokenSpaceGuid.PcdMrIovSupport
3. gEfiMdeModulePkgTokenSpaceGuid.PcdSrIovSuppor
4. gEfiMdeModulePkgTokenSpaceGuid.PcdSrIovSystemPageSize
5. gUefiCpuPkgTokenSpaceGuid.PcdCpuApInitTimeOutInMicroSeconds
6. gUefiCpuPkgTokenSpaceGuid.PcdCpuApLoopMode
7. gUefiCpuPkgTokenSpaceGuid.PcdCpuMicrocodePatchAddress
8. gUefiCpuPkgTokenSpaceGuid.PcdCpuMicrocodePatchRegionSize
Reviewed-by: Gua Guo <gua.guo@intel.com>
Signed-off-by: jdzhang <jdzhang@kunluntech.com.cn>
Allow object to specify the name of processor and processor container
nodes and the UID of processor containers.
This allows these to be more accurately referenced from other tables.
For example for the _PSL method or the UID in the APMT table.
The UID and Name for processor container may be different as if the
intention is to set names as the corresponding affinity level the UID
may need to be different if there are multiple levels of containers.
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4171
A typical QEMU fw_cfg read bytes with IOMMU for td guest is that:
(QemuFwCfgReadBytes@QemuFwCfgLib.c is the example)
1) Allocate DMA Access buffer
2) Map actual data buffer
3) start the transfer and wait for the transfer to complete
4) Free DMA Access buffer
5) Un-map actual data buffer
In step 1/2, Private memories are allocated, converted to shared memories.
In Step 4/5 the shared memories are converted to private memories and
accepted again. The final step is to free the pages.
This is time-consuming and impacts td guest's boot perf (both direct boot
and grub boot) badly.
In a typical grub boot, there are about 5000 calls of page allocation and
private/share conversion. Most of page size is less than 32KB.
This patch allocates a memory region and initializes it into pieces of
memory with different sizes. A piece of such memory consists of 2 parts:
the first page is of private memory, and the other pages are shared
memory. This is to meet the layout of common buffer.
When allocating bounce buffer in IoMmuMap(), IoMmuAllocateBounceBuffer()
is called to allocate the buffer. Accordingly when freeing bounce buffer
in IoMmuUnmapWorker(), IoMmuFreeBounceBuffer() is called to free the
bounce buffer. CommonBuffer is allocated by IoMmuAllocateCommonBuffer
and accordingly freed by IoMmuFreeCommonBuffer.
This feature is tested in Intel TDX pre-production platform. It saves up
to hundreds of ms in a grub boot.
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Rely on CcProbe() to identify when running on TDX so that ACPI tables
can be retrieved differently for Cloud Hypervisor. Instead of relying on
the PVH structure to find the RSDP pointer, the tables are individually
passed through the HOB.
Signed-off-by: Jiaqi Gao <jiaqi.gao@intel.com>
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
Reviewed-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Rely on the CcProbe() function to identify when running on TDX. This
allows the firmware to follow a different codepath for Cloud Hypervisor,
which means it doesn't rely on PVH to find out about memory below 4GiB.
instead it falls back onto the CMOS to retrieve that information.
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
Reviewed-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4186
Commit 079a58276b ("OvmfPkg/AmdSev/SecretPei: Mark SEV launch secret
area as reserved") marked the launch secret area itself (1 page) as
reserved so the guest OS can use it during the lifetime of the OS.
However, the address and size of the secret area held in the
CONFIDENTIAL_COMPUTING_SECRET_LOCATION struct are declared as STATIC in
OVMF (in AmdSev/SecretDxe); therefore there's no guarantee that it will
not be written over by OS data.
Fix this by allocating the memory for the
CONFIDENTIAL_COMPUTING_SECRET_LOCATION struct with the
EfiACPIReclaimMemory memory type to ensure the guest OS will not reuse
this memory.
Fixes: 079a58276b ("OvmfPkg/AmdSev/SecretPei: Mark SEV launch secret ...")
Signed-off-by: Dov Murik <dovmurik@linux.ibm.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
When running under SEV-ES, a page of shared memory is allocated for the
GHCB during the SEC phase at address 0x809000. This page of memory is
eventually passed to the OS as EfiConventionalMemory. When running
SEV-SNP, this page is not PVALIDATE'd in the RMP table, meaning that if
the guest OS tries to access the page, it will think that the host has
voilated the security guarantees and will likely crash.
This patch validates this page immediately after EDK2 switches to using
the GHCB page allocated for the PEI phase.
This was tested by writing a UEFI application that reads to and writes
from one byte of each page of memory and checks to see if a #VC
exception is generated indicating that the page was not validated.
Fixes: 6995a1b79b ("OvmfPkg: Create a GHCB page for use during Sec phase")
Signed-off-by: Adam Dunlap <acdunlap@google.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4179
According to UEFI Spec 2.10 it is supposed to return the mapping from PCR
index to CC MR index:
//
// In the current version, we use the below mapping for TDX:
//
// TPM PCR Index | CC Measurement Register Index | TDX-measurement register
// -----------------------------------------------------------------------
// 0 | 0 | MRTD
// 1, 7 | 1 | RTMR[0]
// 2~6 | 2 | RTMR[1]
// 8~15 | 3 | RTMR[2]
In the current implementation TdMapPcrToMrIndex returns the index of RTMR,
not the MR index.
After fix the spec unconsistent, other related codes are updated
accordingly.
1) The index of event log uses the input MrIndex.
2) MrIndex is decreated by 1 before it is sent for RTMR extending.
Cc: Erdem Aktas <erdemaktas@google.com> [ruleof2]
Cc: James Bottomley <jejb@linux.ibm.com> [jejb]
Cc: Jiewen Yao <jiewen.yao@intel.com> [jyao1]
Cc: Tom Lendacky <thomas.lendacky@amd.com> [tlendacky]
Cc: Arti Gupta <ARGU@microsoft.com>
Reported-by: Arti Gupta <ARGU@microsoft.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Remove global variables, store the state in PlatformInfoHob instead.
Probing for fw_cfg happens on first use, at library initialization
time the Hob might not be present yet.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Tested-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Move the code to a new QemuFwCfgProbe() function. Use direct Io*() calls
instead of indirect QemuFwCfg*() calls to make sure we don't get
recursive calls. Also simplify CC guest detection.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Tested-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Use PlatformInfoHob->FeatureControlValue instead.
OnMpServicesAvailable() will find PlatformInfoHob using
GetFirstGuidHob() and pass a pointer to the WriteFeatureControl
callback.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Tested-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Stop using the mPlatformInfoHob global variable. Let
BuildPlatformInfoHob() allocate and return PlatformInfoHob instead.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Tested-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Stop using the mPlatformInfoHob global variable in S3Verification() and
Q35BoardVerification() functions. Pass a pointer to the PlatformInfoHob
instead.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Tested-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Stop using the mPlatformInfoHob global variable in NoexecDxeInitialization()
function. Pass a pointer to the PlatformInfoHob instead.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Tested-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Stop using the mPlatformInfoHob global variable in MemTypeInfoInitialization()
function. Pass a pointer to the PlatformInfoHob instead.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Tested-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Stop using the mPlatformInfoHob global variable in PublishPeiMemory()
and GetPeiMemoryCap() functions. Pass a pointer to the PlatformInfoHob
instead.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Tested-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Stop using the mPlatformInfoHob global variable in
Q35TsegMbytesInitialization() and
Q35SmramAtDefaultSmbaseInitialization() ) functions.
Pass a pointer to the PlatformInfoHob instead.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Tested-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Stop using the mPlatformInfoHob global variable in PeiFvInitialization()
function. Pass a pointer to the PlatformInfoHob instead.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Tested-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Stop using the mPlatformInfoHob global variable in AmdSevInitialize()
and AmdSevEsInitialize() functions. Pass a pointer to the
PlatformInfoHob instead.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Tested-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
_LPI Revision should be 0 per the ACPI 6.5 specification.
"The revision number of the _LPI object. Current revision is 0."
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
For different compilers, both IA32 and X64 can use
Ia32/CpuFlushTlbGcc.c, which is C code (no inline assembly code).
To simplify, remove other assemly file for CpuFlushTlb,
and rename Ia32/CpuFlushTlbGcc.c to X86CpuFlushTlb.c.
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Ray Ni <ray.ni@intel.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
Update Shell Protocol EfiShellGetMapFromDevicePath() to not
set the end if the device path if it is already an end of
entire device path. This removes a write operation that can
cause failures if the Device Path Protocol is mapped to
read-only memory. In general Device Path Protocols should not
be modified unless the API explicitly states that the device
path is modified.
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Add a new parser for the Arm Performance Monitoring Unit Table.
The APMT table describes the properties of PMU support
implemented by components in an Arm-based system.
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Instead of using hard-coded strings ("0.0.0" for BiosVersion etc)
which is mostly useless read the PCDs (PcdFirmwareVendor,
PcdFirmwareVersionString and PcdFirmwareReleaseDateString) and
build the string table dynamuically at runtime.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
According to the Intel GHCI specification document section 2.4.1, the
goal for instructions that do not have a corresponding TDCALL is for the
handler to treat the instruction as a NOP.
INVD does not have a corresponding TDCALL. This patch makes the #VE
handler treat INVD as a NOP.
Signed-off-by: Ryan Afranji <afranji@google.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
The page allocator code in CoreFindFreePagesI() uses a mask derived from
its UINTN Alignment argument to align the descriptor end address of a
MEMORY_MAP entry to the requested alignment, in order to check whether
the descriptor covers enough sufficiently aligned area to satisfy the
request.
However, on 32-bit architectures, 'Alignment' is a 32-bit type, whereas
DescEnd is a 64-bit type, and so the resulting operation performed on
the end address comes down to masking with 0xfffff000 instead of the
intended 0xffffffff_fffff000. Given the -1 at the end of the expression,
the resulting address is 0xffffffff_fffffffff for any descriptor that
ends on a 4G aligned boundary, and this is certainly not what was
intended.
So cast Alignment to UINT64 to ensure that the mask has the right size.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reported-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Record Argc, Argv and Envp in EmuThunk Ppi so that other modules
can use these fields to change behavior depends on boot parameters
or environment.
Cc: Andrew Fish <afish@apple.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
The persistent memory is for PEIM to use, and won't lose during cold
or warm reset. PcdPersistentMemorySize is only used by WinHost.c,
other modules can check the persistent memory size using the field
PersistentMemorySize.
Cc: Andrew Fish <afish@apple.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
When build in DEBUG, the code asserts that 5LPage support is there
when the physical address width is larger than 48.
In a RELEASE build it will just force LA57 to 1 in CR4
even if CPUID(7).ECX[16] says it is not supported.
UefiCpuPkg: Bug fix in 5LPage handling
The hang (in the ASSERT) in DEBUG is not warranted as there are
legal configurations with CPUID(7).ECX[16](==LA57)=0
and with a physical address width of larger than 48 (like 52).
This is also supported by this code:
https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c#L221
There (as long as physical address width is smaller or equal to 52)
any address width above 48 will be reduced to 48 and the
system can and will work without 5LPaging.
The forced setting of LA57 in CR4 (in the absence of LA57 in CPUID(7).ECX)
is a spec violation and should not happen.
Hence the proposed fix
a) removes the assert.
b) only returns TRUE from Is5LevelPagingNeeded if 5LPaging is actually
supported by HW.
Signed-off-by: Robert Guenzel <robert.guenzel@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4173
Due to more core count increasement, it's hard to reflect all APs
state via AP bitvector support in the register. Actually, SMM CPU
driver doesn't need to check each AP state to know all CPUs in SMI
or not, one alternative method is to check the SMM Delayed & Blocked
AP Count number:
APs in SMI + Blocked Count + Disabled Count >= All supported Aps
(code comments explained why can be > All supported Aps)
With above change, the returned value of "SmmRegSmmEnable" &
"SmmRegSmmDelayed" & "SmmRegSmmBlocked" from SmmCpuFeaturesLib
should be the AP count number within the existing CPU package.
For register that return the bitvector state, require
SmmCpuFeaturesGetSmmRegister() returns count number of all bit per
logical processor within the same package.
For register that return the AP count, require
SmmCpuFeaturesGetSmmRegister() returns the register value directly.
v3:
- Refine the coding style
v2:
- Rename "mPackageBspInfo" to "mPackageFirstThreadIndex"
- Clarify the expected value of "SmmRegSmmEnable" & "SmmRegSmmDelayed" &
"SmmRegSmmBlocked" returned from SmmCpuFeaturesLib.
- Thread: https://edk2.groups.io/g/devel/message/96722
v1:
- Thread: https://edk2.groups.io/g/devel/message/96671
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Zeng Star <star.zeng@intel.com>
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
EmulatorPkg/Win calls LoadLibraryEx() when the corresponding DLL file
is found for each PEIM or DXE driver. The module entry point is
changed to point to the entry point from the DLL. This helps to
notify Visual Studio that a new windows module is loaded and
corresponding symbol parsing is performed for source level debugging.
But entry point from the DLL is only executed when the module is not
loaded by AddModHandle().
When reset happens, we need to clear the DLL loading so that in next
boot the module can be loaded again by AddModHandle().
Without this patch, source level debugging doesn't work after reset.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Zhiguang Liu <zhiguang.liu@intel.com>
Cc: Andrew Fish <afish@apple.com>
With the pending commit of UsbNetworkPkg, it will become common for
UsbBulkTransfer calls to timeout, given that the drivers are called from
MnpSystemPoll every MNP_SYS_POLL_INTERVAL milliseconds: the drivers
check for network packets by calling UsbBulkTransfer with a timeout of
1ms.
Avoid console spam by moving DEBUG messages that occur each time a bulk
transfer request times out from DEBUG_ERROR to DEBUG_VERBOSE, for both
EHCI and XHCI drivers.
Signed-off-by: Rebecca Cran <rebecca@quicinc.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Update ReadfishPkg.dec to remove PrivateInclude from the
[Includes.Common.Private] section. The PrivateInclude directory
does not contain any include files, and the PrivateInclude/Crt
include path remaining in the [Includes.Common.Private] section
providing the include path required to access the CRT related
include files by components within the RedfishPkg.
Without this update, there are two forms of #include statements
that can be used to include the CRT related include files.
Include files should only be available using one form of
#include statements.
Cc: Abner Chang <abner.chang@amd.com>
Cc: Nickle Wang <nicklew@nvidia.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
Reviewed-by: Igor Kulchytskyy <igork@ami.com>
When shutdown is requested, WinHost exits.
Otherwise, WinHost re-runs from SEC.
Tested no extra memory consumption with multiple resets in PEI.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Andrew Fish <afish@apple.com>
Reviewed-by: Zhiguang Liu <zhiguang.liu@intel.com>
In EmulatorPkg/Win, SEC and PEI_CORE are loaded to memory allocated
through VirtualAlloc. Though the corresponding DLL files are loaded
and the entry points in DLL files are executed. The loading to memory
allocated through VirtualAlloc is for the case when the DLL files can
not be loaded.
Actually some PEIMs like PcdPeim which are loaded before
"physical" RAM is discovered, they are executing in the original
location (FV) like XIP module in real platform.
The SEC and PEI_CORE can follow the same mechanism.
So, the VirtualAlloc call is removed.
This is to prepare the "reset" support to avoid additional OS memory
consumption when reset happens.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Zhiguang Liu <zhiguang.liu@intel.com>
Cc: Andrew Fish <afish@apple.com
Move the "physical" RAM allocation from WinPeiAutoScan
to main() entrypoint.
This is to prepare the changes for "reset" support.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Andrew Fish <afish@apple.com>
Reviewed-by: Zhiguang Liu <zhiguang.liu@intel.com>
Fix a typo of "RedfishLibs.dsc.inc" in RedfishLibs.dsc.inc, and correct
the name of the .fdf.inc filename in Redfish.fdf.inc.
Signed-off-by: Rebecca Cran <rebecca@quicinc.com>
Reviewed-by: Nickle Wang <nicklew@nvidia.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
There should be a check that the FV HeaderLength cannot be an odd
number. Otherwise in the following CalculateSum16 there would be an
ASSERT.
In ValidateFvHeader@QemuFlashFvbServicesRuntimeDxe/FwBlockServices.c
there a is similar check to the FwVolHeader->HeaderLength.
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>
Signed-off-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
There was previously a lower bound on the value of TickPeriod such that
it couldn't be less than 10 us. However, that was removed from the PI
Specification in the 1.0 errata released in 2007. From the revision
history:
"M171 Remove 10 us lower bound restriction for the TickPeriod in the
Metronome"
Update the documentation of TickPeriod in MetronomeDxe/Metronome.c to
remove mention of the lower bound.
Signed-off-by: Rebecca Cran <rebecca@quicinc.com>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
DP command should be able to parse the FPDT ACPI table and dump
the ResetEnd which was logged at the beginning of the firmware
image execution. So that DP can calculate SEC phase time duration
start from the beginning of firmware image execution.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Signed-off-by: zhenhuay <zhenhua.yang@intel.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Enables dependabot in this repo so we can better alerted when
dependency updates are available.
This GitHub action will automatically create pull requests and
summarize the dependency details. Because it is a pull request,
the CI system will validate the dependency update in the pull
request.
Configures dependabot for:
1. PIP module updates
2. GitHub action updates
The maintainers/reviewers of the .github directory were added as
pull request reviewers so they can be notified when the pull request
is available.
Note to Maintainers:
After this change is committed, PRs from dependabot will be
automatically created in the edk2 repo. Never set the 'push' label
directly on these PRs. If a dependency identified by dependedabot
looks like one that should be updated in the edk2 repo, then copy
the PR generated by dependabot to your personal fork and update the
commit message to follow the edk2 commit message requirements and
send as a normal code review.
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Sean Brogan <sean.brogan@microsoft.com>
Remove ASSERTs in ArmTrngLibConstructor() that prevent from
booting on DEBUG builds.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
2022-11-26 14:42:41 +00:00
1180 changed files with 72176 additions and 17677 deletions
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
