The block size configuration of Blockmap does not match that in Qemu
VirtNorFlash, which causes variable data to be written into FtwWorkBlock
by mistake, resulting in data loss during reboot. Fix it and update
new checksum value.
Signed-off-by: Qingyu Shang <2931013282@sjtu.edu.cn>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
Currently, HeapGuard, when in the GuardAlignedToTail mode, assumes that
the pool head has been allocated in the first page of memory that was
allocated. This is not the case for ARM64 platforms when allocating
runtime pools, as RUNTIME_PAGE_ALLOCATION_GRANULARITY is 64k, unlike
X64, which has RUNTIME_PAGE_ALLOCATION_GRANULARITY as 4k.
When a runtime pool is allocated on ARM64, the minimum number of pages
allocated is 16, to match the runtime granularity. When a small pool is
allocated and GuardAlignedToTail is true, HeapGuard instructs the pool
head to be placed as (MemoryAllocated + EFI_PAGES_TO_SIZE(Number of Pages)
- SizeRequiredForPool).
This gives this scenario:
|Head Guard|Large Free Number of Pages|PoolHead|TailGuard|
When this pool goes to be freed, HeapGuard instructs the pool code to
free from (PoolHead & ~EFI_PAGE_MASK). However, this assumes that the
PoolHead is in the first page allocated, which as shown above is not true
in this case. For the 4k granularity case (i.e. where the correct number of
pages are allocated for this pool), this logic does work.
In this failing case, HeapGuard then instructs the pool code to free 16
(or more depending) pages from the page the pool head was allocated on,
which as seen above means we overrun the pool and attempt to free memory
far past the pool. We end up running into the tail guard and getting an
access flag fault.
This causes ArmVirtQemu to fail to boot with an access flag fault when
GuardAlignedToTail is set to true (and pool guard enabled for runtime
memory). It should also cause all ARM64 platforms to fail in this
configuration, for exactly the same reason, as this is core code making
the assumption.
This patch removes HeapGuard's assumption that the pool head is allocated
on the first page and instead undoes the same logic that HeapGuard did
when allocating the pool head in the first place.
With this patch in place, ArmVirtQemu boots with GuardAlignedToTail
set to true (and when it is false, also).
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4521
Github PR: https://github.com/tianocore/edk2/pull/4731
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Dandan Bi <dandan.bi@intel.com>
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
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: Corvin Köhne <corvink@FreeBSD.org>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
The implementation of this new behavior aligns with the guidelines
outlined in the Intel SDM.
Following a power-up or RESET of an MP system, system hardware
dynamically selects one of the processors on the system bus as the BSP.
The remaining processors are designated as APs. The APs complete a
minimal self-configuration, then wait for a startup signal (a SIPI
message) from the BSP processor.
Additionally, the MP protocol is executed only after
a power-up or RESET. If the MP protocol has completed and a
BSP is chosen, subsequent INITs (either to a specific processor or
system wide) do not cause the MP protocol to be repeated. Instead, each
logical processor examines its BSP flag (in the IA32_APIC_BASE MSR) to
determine whether it should execute the BIOS boot-strap code (if it is
the BSP) or enter a wait-for-SIPI state (if it is an AP).
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
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>
Rewrite the script to configure openssl 3.0 from scratch. It's two
scripts now:
* Tiny helper script, dumping the perl configdata as json.
* Actual configure.py script, written in python, which copies over
the generated files to openssl-gen and updates the OpensslLib*.inf
file lists and build flags.
The configuration workflow has changed a bit:
* All generated files are stored in the OpensslGen directory tree.
* For ec/no-ec builds two different header files are used. Default is
the ec variant, and the new EDK2_OPENSSL_NOEC define is used to
select the no-ec build. A five line wrapper include is used to pick
the one or the other.
* For non-accel builds -DOPENSSL_NO_ASM on the command line is used
(same as before).
* For configration defines the OPENSSL_FLAGS_$(variant) variable is
used, where variant is the architecture for the accelerated builds
and 'NOASM' for the non-accelerated builds.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Yi Li <yi1.li@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Xiaoyu Lu <xiaoyu1.lu@intel.com>
Cc: Guomin Jiang <guomin.jiang@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Brian J. Johnson <brian.johnson@hpe.com>
Tested-by: Kenneth Lautner <klautner@microsoft.com>
If gST->ConOut is available when Arm's DefaultExceptionHandler is
running, AsciiPrint will get called to attempt to print to ConOut, in
addition to the serial output.
AsciiPrint calls AsciiInternalPrint in UefiLibPrint.c which in turn
calls AllocatePool to allocate a buffer to convert the Ascii input
string to a Unicode string to pass to ConOut->OutputString.
Per the comment on DefaultExceptionHandler, we should not be allocating
memory in the exception handler, as this can cause the exception handler
to fail if we had a memory exception or the system state is such that we
cannot allocate memory.
It has been observed on ArmVirtQemu that exceptions generated in the
memory handling code will fail to output the stack dump and CPU state
that is critical to debugging because the AllocatePool will fail.
This patch fixes the Arm and AARCH64 DefaultExceptionHandlers to not
allocate memory when ConOut is available and instead use stack memory to
convert the Ascii string needed for SerialPortWrite to the Unicode
string needed for ConOut->OutputString. Correspondingly, ArmVirtQemu can
now output the stack dump and CPU state when hitting an exception in
memory code.
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
For EfiVarStore (EFI_HII_VARSTORE_EFI_VARIABLE_BUFFER), it will call
ExtractConfig-GetVariable-HiiBlockToConfig-ConfigToBlock when load storage
value in LoadStorage function. It's not necessary and costs lots of time
to do the conversion between config and block.
So now enhance it to call GetVariable directly.
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Eric Dong <eric.dong@intel.com>
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Eric Dong <eric.dong@intel.com>
The return value stored in Status after call to SetDriveParameters
is not made of any use thereafter and hence it remains as UNUSED.
Based on Hao's findings (https://edk2.groups.io/g/devel/message/106844),
the successful execution of SetDriveParameters() is not mandatory for
initializing IDE mode of a hard disk device. Hence remove the 'Status'
assignment of the return value from SetDriveParameters() and instead add
error checks & DEBUG_WARN level messages within SetDriveParameters()
function after sending INIT_DRIVE_PARAM & SET_MULTIPLE_MODE ATA commands.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4204
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Ranbir Singh <Ranbir.Singh3@Dell.com>
Signed-off-by: Ranbir Singh <rsingh@ventanamicro.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
The purpose is to fix an issue where an exception occurs at the start
of the DXE phase by applying the following patch series on INTEL-based
systems.
UefiCpuPkg: Refactor the logic for placing APs in HltLoop.
UefiCpuPkg: Refactor the logic for placing APs in Mwait/Runloop.
UefiCpuPkg: Create MpHandOff.
UefiCpuPkg: ApWakeupFunction directly use CpuMpData.
UefiCpuPkg: Eliminate the second INIT-SIPI-SIPI sequence.
This series of patches makes changes to the way the APs are
initialized and woken up. It removes the 2nd time INIT-SIPI-SIPI and
introduces a special startup signal to wake up APs. These patches also
create a new HOB identified by the mMpHandOffGuid, which stores only the
minimum information required from the PEI phase to the DXE phase.
As a result, the original HOB (mCpuInitMpLibHobGuid) is now used only
as a global variable in the PEI phase and is no longer necessary in the
DXE phase for INTEL-based systems. The AMD SEV-ES related code
still relies on the OldCpuMpData in the DXE phase.
This patch decouple the SEV-ES functionality of assigning CpuMpData to
OldCpuMpData->NewCpuMpData from the Intel logic.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com>
- Add NTOHL() for coverting IP address from EFI_IPv4_ADDRESS to
IP4_ADDR so that IP4_IS_VALID_NETMASK() return correct value.
- Add DumpIpv4Address() in RedfishDebugLib and print IP address
when invalid IP or subnet mask address is detected.
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>
Reviewed-by: Abner Chang <abner.chang@amd.com>
Remove workaround for the redefinition of the type
RUNTIME_FUNCTION that is generated when building with
VS20xx tool chains and using windows include files.
The correct location for this fix is in the EmulatorPkg
in the WinInclude.h file that addresses all the name
collisions between edk2 types and windows types.
The commit that added the workaround is:
ff52068d92
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Rebecca Cran <rebecca@bsdio.com>
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: Rebecca Cran <rebecca@bsdio.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4467
Current implementation of UnitTestFrameworkPkg for shell-based unit test
will save the unit test cache to the same volume as the test application
itself. This works as long as the test application is on a writable
volume, such as USB or EFI partition.
Instead of saving the files to the same file system of unit test
application, this change will save the cache file to the path where the
user ran this test application.
This change then added an input argument to allow user to specify where
to save such cache file through `--CachePath` shell argument to allow
even more flexibility.
This change was tested on proprietary physical hardware platforms and
QEMU based virtual platform.
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: Kun Qin <kuqin12@gmail.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Searching for an unused bounce buffer in mReservedMemBitmap and
reserving the buffer by flipping the bit is a critical section
which must not be interrupted. Raise the TPL level to ensure
that.
Without this fix it can happen that IoMmuDxe hands out the same
bounce buffer twice, causing trouble down the road. Seen happening
in practice with VirtioNetDxe setting up the network interface (and
calling into IoMmuDxe from a polling timer callback) in parallel with
Boot Manager doing some disk I/O. An ASSERT() in VirtioNet caught
the buffer inconsistency.
Full story with lots of details and discussions is available here:
https://bugzilla.redhat.com/show_bug.cgi?id=2211060
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
The function UsbHcGetPciAddressForHostMem has
ASSERT ((Block != NULL));
and the UsbHcFreeMem has
ASSERT (Block != NULL);
statement after for loop, but these are applicable only in DEBUG mode.
In RELEASE mode, if for whatever reasons there is no match inside the
for loop and the loop exits because of Block != NULL; condition, then
there is no "Block" NULL pointer check afterwards and the code proceeds
to do dereferencing "Block" which will lead to CRASH.
Hence, for safety add NULL pointer checks always.
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4210
Signed-off-by: Ranbir Singh <Ranbir.Singh3@Dell.com>
Signed-off-by: Ranbir Singh <rsingh@ventanamicro.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Make sure VirtNorFlashDxe loaded before VariableRuntimeDxe as it
is the backend flash driver.
Signed-off-by: Tuan Phan <tphan@ventanamicro.com>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
Normally, DXE driver would add device resource to GCD before start using.
But some key resources such as uart used for printing info at very early
stage.
Those resources should be populated to HOB in SEC phase so they are
added to GCD before MMU enabled.
Signed-off-by: Tuan Phan <tphan@ventanamicro.com>
Reviewed-by: Andrei Warkentin <andrei.warkentin@intel.com>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
Commit 63c50d3ff2 changed the check that is
used to determine if SEV-ES is active. Originally, a CMP instruction with
a supporting JZ instruction was used for the check. It was changed to use
the BT instruction but not JZ instruction. The result of a BT instruction
changes the the carry flag (CF) and not the zero flag (ZF). As a result,
the wrong condition is being checked. Update the JZ to a JNC to properly
detect if SEV-ES is active.
Fixes: 63c50d3ff2 ("OvmfPkg/ResetVector: cache the SEV status MSR...")
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
When both the PEI and DXE phases operate in the same execution
mode(32-bit/64-bit), the BSP send a special start-up signal during
the DXE phase to awaken the Application APs.
To eliminate the need for the INIT-SIPI-SIPI sequence at the beginning
of the DXE phase, the BSP call the SwitchApContext function to trigger
the special start-up signal. By writing the specified
StartupSignalValue to the designated StartupSignalAddress, the BSP
wakes up the APs from mwait mode. Once the APs receive the
MP_HAND_OFF_SIGNAL value, they are awakened and proceed to execute the
SwitchContextPerAp procedure. They enter another while loop,
transitioning their context from the PEI phase to the DXE phase.
The original state transitions for an AP during the procedure are as
follows:
Idle ----> Ready ----> Busy ----> Idle
[BSP] [AP] [AP]
Instead of init-sipi-sipi sequence, we make use of a
start-up signal to awaken the APs and transfer their context from
PEI to DXE. Consequently, APs, rather than the BSP, to set their state
to CpuStateReady.
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com>
In the original design, once the APs finished executing their assembly
code and switched to executing C code, they would enter a continuous
loop within a function. In this function, they would collect CpuMpData
using the MP_CPU_EXCHANGE_INFO mechanism. However, in the updated
approach, CpuMpData can now be passed directly to the ApWakeUpFunction,
bypassing the need for MP_CPU_EXCHANGE_INFO. This modification is made
in preparation for eliminating the requirement of a second
INIT-SIPI-SIPI sequence in the DXE phase.
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com>
Initially, the purpose of the Hob was twofold: it served as a way to
transfer information from PEI to DXE. However, during the DXE phase,
only a few fields from the CPU_MP_DATA which collected in PEI phase were
needed. A new Hob was specifically created to transfer information
to the DXE phase. This new Hob contained only the essential fields
required for reuse in DXE. For instance, instead of directly including
the BspNumber in MpHandOff, the DXE phase introduced the use of
GetBspNumber() to collect the BspNumber from ApicID and CpuCount.
The SaveCpuMpData() function was updated to construct the MP_HAND_OFF
Hob. Additionally, the function introduced the MP_HAND_OFF_SIGNAL,
which solely served the purpose of awakening the APs
and transitioning their context from PEI to DXE. The
WaitLoopExecutionMode field indicated whether the bit mode of PEI
matched that of DXE. Both of them were filled only if the ApLoopMode
was not ApInHltLoop. In the case of ApInHltLoop, it remained necessary
to wake up the APs using the init-sipi-sipi sequence. This improvement
still allow INIT-SIPI-SIPI even APs are wait in Run/Mwait loop mode.
The function GetMpHandOffHob() was added to facilitate access to the
collected MpHandOff in the DXE phase. The CpuMpData in the DXE phase
was updated by gathering information from MpHandOff. Since MpHandOff
replaced the usage of OldCpuMpData and contained essential information
from the PEI phase to the DXE phase. AmdSevUpdateCpuMpData was included
to maintain the original implementation of AmdSev, ensuring that
OldCpuMpData->NewCpuMpData pointed to CpuMpData.
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4410
Inside TcgMorLockSmm.c, the SetVariableCheckHandlerMorLock() function
contains a scenario to prevent a possible dictionary attack on the MorLock
Key in accordance with the TCG Platform Reset Mitigation Spec v1.10.
The mechanism to prevent this attack must also change the MorLock Variable
Value to 0x01 to indicate Locked Without Key.
ASSERT_EFI_ERROR is added for error visibility since SetMorLockVariable
returns a status code
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Abhi Singh <Abhi.Singh@arm.com>
Acked-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Introduce DumpHiiStatementValue() and DumpRedfishValue() to
RedfishDebugLib. Application uses these functions to debug
print the value of HII_STATEMENT_VALUE and EDKII_REDFISH_VALUE.
Signed-off-by: Nickle Wang <nicklew@nvidia.com>
Cc: Abner Chang <abner.chang@amd.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
RedfishRestExDxe driver failed to uninstall service binding protocol
when driver binding stop is called. Application drivers may still
use RedfishRestExDxe after it is disconnected in system.
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>
Much of the MMU logic was written without function headers. This patch
adds function headers where absent and updates function headers which
do not match the EDK2 standard.
Signed-off-by: Taylor Beebe <t@taylorbeebe.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
There are ASSERTs present in the MMU logic to ensure various
functions return successfully, but these ASSERTs may be ignored
on release builds causing unsafe behavior. This patch updates
the logic to handle unexpected return values and branch safely.
Signed-off-by: Taylor Beebe <t@taylorbeebe.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
This patch updates the GetMemoryRegion() function to handle the case
where there is no mapping for the requested address.
The original logic for the ARM would hit an ASSERT after
GetMemoryRegionPage() returned EFI_SUCCESS but did not update The
RegionLength parameter.
The original logic for the AARCH64 would never initialize the
RegionLength parameter to zero and return EFI_SUCCESS after
traversing an unknown number of pages.
To fix this, update the logic for both architecture to return
EFI_NO_MAPPING if the BaseAddress being checked is unmapped.
Signed-off-by: Taylor Beebe <t@taylorbeebe.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
This patch applies Uncrustify to the following files:
ArmPkg/Drivers/MmCommunicationPei/MmCommunicationPei.c
ArmPkg/Include/IndustryStandard/ArmStdSmc.h
Signed-off-by: Taylor Beebe <t@taylorbeebe.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4182
Adds an SMM SMRAM save-state map for AMD processors.
SMRAM save state maps for the AMD processor family are now supported.
Save state map structure is added based on
AMD64 Architecture Programmer's Manual, Volume 2, Section 10.2.
The AMD legacy save state map for 32-bit architecture is defined.
The AMD64 save state map for 64-bit architecture is defined.
Also added Amd/SmramSaveStateMap.h to IgnoreFiles of EccCheck,
because structures defined in this file are derived from
Intel/SmramSaveStateMap.h.
Cc: Paul Grimes <paul.grimes@amd.com>
Cc: 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>
Signed-off-by: Abdul Lateef Attar <abdattar@amd.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
The timer notify function should be called with timer period, not the
value read from timer register.
Signed-off-by: Tuan Phan <tphan@ventanamicro.com>
This commit is code refinement to current smm runtime InitPaging()
page table update code. In InitPaging(), if PcdCpuSmmProfileEnable
is TRUE, use ConvertMemoryPageAttributes() API to map the range in
mProtectionMemRange to the attrbute recorded in the attribute field
of mProtectionMemRange, map the range outside mProtectionMemRange
as non-present. If PcdCpuSmmProfileEnable is FALSE, only need to
set the ranges not in mSmmCpuSmramRanges as NX.
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>
Cc: Gerd Hoffmann <kraxel@redhat.com>
This commit is code refinement to current smm pagetable generation
code. Add a new GenSmmPageTable() API to create smm page table
based on the PageTableMap() API in CpuPageTableLib. Caller only
needs to specify the paging mode and the PhysicalAddressBits to map.
This function can be used to create both IA32 pae paging and X64
5level, 4level paging.
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>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Clear CR0.WP before modify smm page table. Currently, there is
an assumption that smm pagetable is always RW before ReadyToLock.
However, when AMD SEV is enabled, FvbServicesSmm driver calls
MemEncryptSevClearMmioPageEncMask to clear AddressEncMask bit
in smm page table for this range:
[PcdOvmfFdBaseAddress,PcdOvmfFdBaseAddress+PcdOvmfFirmwareFdSize]
If page slpit happens in this process, new memory for smm page
table is allocated. Then the newly allocated page table memory
is marked as RO in smm page table in this FvbServicesSmm driver,
which may lead to PF if smm code doesn't clear CR0.WP before
modify smm page table when ReadyToLock.
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>
Cc: Gerd Hoffmann <kraxel@redhat.com>
In PiSmmCpuDxeSmm code, SetMemMapAttributes() marks memory ranges
in SmmMemoryAttributesTable to RO/NX. There may exist non-present
range in these memory ranges. Set other attributes for a non-present
range is not permitted in CpuPageTableMapLib. So add code to handle
this case. Only map the present ranges in SmmMemoryAttributesTable
to RO or NX.
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>
Cc: Gerd Hoffmann <kraxel@redhat.com>
In ConvertMemoryPageAttributes() function, when clear RP for a
specific range [BaseAddress, BaseAddress + Length], it means to
set the present bit to 1 and assign default value for other
attributes in page table. The default attributes for the input
specific range are NX disabled and ReadOnly. If there is existing
present range in [BaseAddress, BaseAddress + Length] and the
attributes are not NX disabled or not ReadOnly, then output the
DEBUG message to indicate that the NX and ReadOnly attributes of
the existing present range are modified in the function.
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>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Simplify the ConvertMemoryPageAttributes API to convert paging
attribute by CpuPageTableLib. In the new API, it calls
PageTableMap() to update the page attributes of a memory range.
With the PageTableMap() API in CpuPageTableLib, we can remove
the complicated page table manipulating code.
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>
Cc: Gerd Hoffmann <kraxel@redhat.com>
In UnsetGuardPage(), before SmmReadyToLock, remove NX and RO
memory attribute protection for guarded page since
EfiConventionalMemory in SMRAM is RW and executable before
SmmReadyToLock. If UnsetGuardPage() happens after SmmReadyToLock,
then apply EFI_MEMORY_XP to the guarded page to make sure
EfiConventionalMemory in SMRAM is NX since EfiConventionalMemory
in SMRAM is marked as NX in PiSmmCpuDxe driver when SmmReadyToLock.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Ray Ni <ray.ni@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Remove code that sets AddressEncMask for non-leaf entries when
modifing smm page table by MemEncryptSevLib. In FvbServicesSmm
driver, it calls MemEncryptSevClearMmioPageEncMask to clear
AddressEncMask bit in page table for a specific range. In AMD
SEV feature, this AddressEncMask bit in page table is used to
indicate if the memory is guest private memory or shared memory.
But all memory accessed by the hardware page table walker is
treated as encrypted, regardless of whether the encryption bit
is present. So remove the code to set the EncMask bit for smm
non-leaf entries doesn't impact AMD SEV feature.
The reason encryption mask should not be set for non-leaf
entries is because CpuPageTableLib doesn't consume encryption
mask PCD. In PiSmmCpuDxeSmm module, it will use CpuPageTableLib
to modify smm page table in next patch. The encryption mask is
overlapped with the PageTableBaseAddress field of non-leaf page
table entries. If the encryption mask is set for smm non-leaf
page table entries, issue happens when CpuPageTableLib code
use the non-leaf entry PageTableBaseAddress field with the
encryption mask set to find the next level page table.
Signed-off-by: Dun Tan <dun.tan@intel.com>
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>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
The UEFI driver model invokes the supported() method on every driver
every time a connection attempt is made on any handle, and so doing an
unconditional DEBUG() print inside this method produced a lot of noise.
So let's drop this DEBUG() call from the VirtioSerial driver's
Supported() method.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
The OP-TEE secure OS exposes a non-secure memory region for
communication between the secure OS itself and any clients in the
non-secure firmware. This memory is writable by non-secure and is not
used for code only data, and so it should be mapped non-executable.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Now that we have a sane API to set and clear memory permissions that
works the same on ARM and AArch64, we no longer have a need for the
individual set/clear no-access/read-only/no-exec helpers so let's drop
them.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
StandaloneMm has its own version of the ArmMmuLib library class, but
includes the ArmMmuLib header. This happens to work because the
prototypes that are referenced are the same, but this will no longer be
the case after a future patch. So correct the #includes.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Because it's simpler for a platform to include the ResetVector source
and having pre-built binaries add burdens of updating the pre-built
binaries. This patch removes the pre-built binaries and the script
that buids the pre-built binaries.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
ResetVector assembly implementation puts "ALIGN 16" in the end
to guarantee the final executable file size is multiple of 16 bytes.
Because the module uses a special GUID which guarantees it's put in
the very end of a FV, which should be also the end of the FD.
All of these (file size is multiple of 16B, and the module is put at
end of FV, FV is put at end of FD) guarantee the "JMP xxx" instruction
is at FFFF_FFF0h.
This patch updates INF file and ReadMe.txt to add guidance of FDF ffs
rule for the ResetVector.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Now that ArmSetMemoryAttributes() permits a mask to be provided, we can
simplify the implementation the UEFI memory attribute protocol
substantially, and just pass on the requested mask to be set or cleared
directly.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Now that we have a generic method to manage memory permissions using a
PPI, we can switch to the generic version of the DXE handoff code in
DxeIpl, and drop the ARM specific version.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
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>
Implement the newly defined PPI that permits the PEI core and DXE IPL to
manage memory permissions on ranges of DRAM, for doing things like
mapping the stack non-executable, or granting executable permissions to
shadowed PEIMs.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Currently, ArmSetMemoryAttributes () takes a combination of
EFI_MEMORY_xx constants describing the memory type and permission
attributes that should be set on a region of memory. In cases where the
memory type is omitted, we assume that the memory permissions being set
are final, and that existing memory permissions can be discarded.
This is problematic, because we aim to map memory non-executable
(EFI_MEMORY_XP) by default, and only relax this requirement for code
regions that are mapped read-only (EFI_MEMORY_RO). Currently, setting
one permission clears the other, and so code managing these permissions
has to be aware of the existing permissions in order to be able to
preserve them, and this is not always tractable (e.g., the UEFI memory
attribute protocol implements an abstraction that promises to preserve
memory permissions that it is not operating on explicitly).
So let's add an AttributeMask parameter to ArmSetMemoryAttributes(),
which is permitted to be non-zero if no memory type is being provided,
in which case only memory permission attributes covered in the mask will
be affected by the update.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
If the associated PCD is set to TRUE, use the memory attribute PPI to
remap the stack non-executable. This provides a generic method for doing
so, which will be used by ARM and AArch64 as well once they move to the
generic DxeIpl handoff implementation.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
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 Risc-V and LoongArch specific versions of the DXE core handoff code
in DxeIpl are essentially copies of the EBC version (modulo the
copyright in the header and some debug prints in the code).
In preparation for introducing a generic PPI based method to implement
the non-executable stack, let's merge these versions, so we only need to
add this logic once.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
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>
Define a PPI interface that may be used by the PEI core or other PEIMs
to manage permissions on memory ranges. This is primarily intended for
restricting permissions to what is actually needed for correct execution
by the code in question, and for limiting the use of memory mappings
that are both writable and executable at the same time.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
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>
Bhyve will gain support for TPM emulation in the near future. Therefore,
prepare OVMF by copying all TPM driver used by qemu's OVMF DSC into the
bhyve OVMF DSC.
Signed-off-by: Corvin Köhne <corvink@FreeBSD.org>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
This makes the InstallQemuFwcfgTables function reusable by bhyve.
Signed-off-by: Corvin Köhne <corvink@FreeBSD.org>
Acked-by: Peter Grehan <grehan@freebsd.org>
This is required to move InstallQemuFwCfgTables into AcpiPlatformLib.
Signed-off-by: Corvin Köhne <corvink@FreeBSD.org>
Acked-by: Peter Grehan <grehan@freebsd.org>
Bhyve supports providing ACPI tables by FwCfg. Therefore,
InstallQemuFwCfgTables should be moved to AcpiPlatformLib to reuse the
code. As first step, move PciEncoding into AcpiPlatformLib.
Signed-off-by: Corvin Köhne <corvink@FreeBSD.org>
Acked-by: Peter Grehan <grehan@freebsd.org>
The definition and declaration of GetAcpiRsdpFromMemory doesn't match.
We don't get a compile error yet because UINTN is the same as UINT64 on
64bit machines. As the function works on memory addresses, UINTN is the
correct type of the input parameters.
Signed-off-by: Corvin Köhne <corvink@FreeBSD.org>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Peter Grehan <grehan@freebsd.org>
Currently, RiscVVirtQemu supports unified code and variable store
mainly because only one pflash devices was available in qemu for
EDK2. However, this doesn't allow to map the code part as read-only.
With recent qemu enhancements, it is now possible for EDK2 to make
use of both pflash devices in RISC-V virt machine. So, add support
to create code and vars images separately. This also allows easy
firmware code updates without losing the variable store.
Signed-off-by: Sunil V L <sunilvl@ventanamicro.com>
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>
Cc: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
This commit is code optimization to InternalAllocateAlignedPages of
SmmMemoryAllocationLib which can reduce free memory fragments. Also
it can reduce one pre-allocation page.
Let's take a simple example:
The expected pages size is 8KB, Alignment value is 8KB.
In original InternalAllocateAlignedPages(), the first step is to
allocate 4 pages and then find the first 8KB-aligned address in
allocated 4 pages. If the upper limit address of allocated 4 pages
is already 8KB aligned, then the allocated 4 pages contains two
8KB-aligned 8KB ranges. The lower 2 pages will be selected and
removed from free pages. Then the higher 2 pages will be free.
Since the whole memory allocation is from high address to low
address, then the higher 2 pages cann't be merged with other free
pages, causing the free memory fragments.
However, when only allocate 3(2+2-1) pages, we can avoid the free
memory fragments in specific case. Also 3 pages must contain a
8KB-aligned 8KB range, which meets the requirement. If the upper
limit address of allocated 3 pages is 8KB-aligned, then the higher
2 pages range of allocated 3 pages is 8KB-aligned and will be
selected and removed from free pages. The remaining lower one page
of allocated 3 pages will be free and merged with left lower free
memory. This can reduce free memory fragments in smm.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
When a platform has lots of CPU cores/threads, perf-logging on every
AP produces lots of records. When this multiplies with number of SMIs
during post, the records are even more.
So, this patch adds a new PCD PcdSmmApPerfLogEnable (default TRUE)
to allow platform to turn off perf-logging on APs.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiaxin Wu <jiaxin.wu@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
MP procedures are those procedures that run in every CPU thread.
The EDKII perf infra is not MP safe so it doesn't support to be called
from those MP procedures.
The patch adds SMM MP perf-logging support in SmmMpPerf.c.
The following procedures are perf-logged:
* SmmInitHandler
* SmmCpuFeaturesRendezvousEntry
* PlatformValidSmi
* SmmCpuFeaturesRendezvousExit
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Reviewed-by: Jiaxin Wu <jiaxin.wu@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
This library supports a PeiServicesTablePointerLib implementation
that allows code dependent upon PeiServicesTable to operate in an
isolated execution environment such as within the context of a
host-based unit test framework.
The unit test should initialize the PeiServicesTable database with
any required elements (e.g. PPIs, Hob etc.) prior to the services
being invoked by code under test.
It is strongly recommended to clean any global databases by using
EFI_PEI_SERVICES.ResetSystem2 after every unit test so the tests
execute in a predictable manner from a clean state.
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Michael Kubacki <mikuback@linux.microsoft.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
Currently, have two command for pre-build binary support
1. --BuildEntryOnly: build UPL Entry file
2. --PreBuildUplBinary: build UPL binary based on UPL
And these two commands should be exclusived, shouldn't
have chance run it in the meantime.
Case1: Build UPL entry with CLANGDWARF
python UefiPayloadPkg/UniversalPayloadBuild.py --BuildEntryOnly
Case2: Use pre-built UPL entry and build other fv by VS2019
python UefiPayloadPkg/UniversalPayloadBuild.py -t VS2019 \
--PreBuildUplBinary UniversalPayload.elf
Case3: Build UPL Entry with CLANGDWARF and build other fv by VS2019
python UefiPayloadPkg/UniversalPayloadBuild.py -t VS2019
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: Gua Guo <gua.guo@intel.com>
Reviewed-by: James Lu <james.lu@intel.com>
RedfishClientPkg is moved from edk2-staging repository to
edk2-redfish-client repository. Update the link in Readme.md
to new location.
Signed-off-by: Nickle Wang <nicklew@nvidia.com>
Cc: Abner Chang <abner.chang@amd.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
If there is no port multiplier, PortMultiplierPort should be converted
to 0 to follow AHCI spec.
The same logic already applied in AtaAtapiPassThruDxe driver.
Signed-off-by: Neo Hsueh <Hong-Chih.Hsueh@amd.com>
Acked-by: Abner Chang <abner.chang@amd.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Implement the SpeculationBarrier with implementations consisting of
fence instruction which provides finer-grain memory orderings.
Perform Data Barrier in RiscV: fence rw,rw
Perform Instruction Barrier in RiscV: fence.i; fence r,r
More detail is in Appendix A: RVWMO Explanatory Material in
https://github.com/riscv/riscv-isa-manual
This API is first introduced in the below commits for IA32 and x64
d9f1cac51be83d841fdc
and below the commit for ARM and AArch64 implementation
c0959b4426
This commit is to add the RiscV64 implementation which will be used by
variable service under Variable/RuntimeDxe
Cc: Andrei Warkentin <andrei.warkentin@intel.com>
Cc: Evan Chai <evan.chai@intel.com>
Cc: Sunil V L <sunilvl@ventanamicro.com>
Cc: Tuan Phan <tphan@ventanamicro.com>
Signed-off-by: Yong Li <yong.li@intel.com>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
It's much easier to create configuration dependent ACPI tables for bhyve
than for OVMF. For this reason, don't use the statically created ACPI
tables provided by OVMF. Instead, prefer the dynamically created ACPI
tables of bhyve. If bhyve provides no ACPI tables or we are unable to
detect those, fall back to OVMF tables.
Ideally, we use the qemu fwcfg interface to pass the ACPI tables from
bhyve to OVMF. bhyve will support this in the future. However, current
bhyve executables don't support passing ACPI tables by the qemu fwcfg
interface. They just copy the ACPI into main memory. For that reason,
pick up the ACPI tables from main memory.
Signed-off-by: Corvin Köhne <corvink@FreeBSD.org>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Acked-by: Peter Grehan <grehan@freebsd.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Xen and bhyve are placing ACPI tables into system memory. So, they can
share the same code. Therefore, create a new library which searches and
installs ACPI tables from system memory.
Signed-off-by: Corvin Köhne <corvink@FreeBSD.org>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Edk2 was failing, rather than creating more PML4 entries, when they
weren't present in the initial memory acceptance flow. Because of that
VMs with more than 512G memory were crashing. This code fixes that.
This change affects only SEV-SNP VMs.
The code was tested by successfully booting a 512G SEV-SNP VM.
Signed-off-by: Mikolaj Lisik <lisik@google.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
The RISC-V version of the DXE IPL does not implement setting the stack
NX, so before switching to an implementation that will ASSERT() on the
missing support, drop the PCD setting that enables it.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
Uncrustify checks are too rigid, making them counter-productive:
- it leads to code that is arguably harder to parse visually (e.g.,
the changes to ArmPkg/Include/Chipset/AArch64Mmu.h in commit
429309e0c6)
- it forces indentation-only changes to code in the vicinity of actual
changes, making the code history more bloated than necessary (see
commit 7f198321ee for an example)
- finding out from the web UI what exactly Uncrustify objected to is not
straight-forward.
So let's enable AuditMode for ArmPkg, so that interested parties can see
the uncrustify recommendations if desired, but without preventing the
changes from being merged. This leaves it at the discretion of the
ArmPkg maintainers to decide which level of conformance is required.
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: "Kinney, Michael D" <michael.d.kinney@intel.com>
Cc: Michael Kubacki <mikuback@linux.microsoft.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
In case ShellConvertStringToUint64() fails the Handles are left
uninitialized. That can for example happen for Handle2 and Handle3 in
case only one parameter was specified on the command line. Which can
trigger the ASSERT() in line 185.
Reproducer: boot ovmf to efi shell in qemu, using q35 machine type, then
try disconnect the sata controller in efi shell.
Fix that by explicitly setting them to NULL in that case. While being
at it also simplify the logic and avoid pointlessly calling
ShellConvertStringToUint64() in case ParamN is NULL.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
As per the SMBIOS spec, in smbios type0 table, if the Bios size is
greater than 16MB, extended bios size is used to update size information
and bios size is set to 0xff. when this data is printed by smbiosview,
both bios size and extended bios size is printed if the smbios version
is beyond 3.1, which is incorrect as Bios size is set to 0xff when
rom size is more than 16MB.
To fix this bug, added a condition to print bios size only when it is
not set to 0xff or if the smbios version is older than 3.1.
Signed-off-by: Thejaswani Putta <tputta@nvidia.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Now that OvmfPkg/SataControllerDxe and its MdeModulePkg counterpart have
been unified, and no in-tree uses of the OVMF variant remain, let's
delete it.
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Replace the OVMF-specific SataControllerDxe (to be later removed) with
the generic, MdeModulePkg one, for the OvmfXen platform.
Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Anthony PERARD <anthony.perard@citrix.com>
Replace the OVMF-specific SataControllerDxe (to be later removed) with
the generic, MdeModulePkg one, for the AmdSev platform.
Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Replace the OVMF-specific SataControllerDxe (to be later removed) with
the generic, MdeModulePkg one, for the IntelTdx platform.
Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Replace the OVMF-specific SataControllerDxe (to be later removed) with
the generic, MdeModulePkg one, for the CloudHv platform.
Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Replace the OVMF-specific SataControllerDxe (to be later removed) with
the generic, MdeModulePkg one, for the Microvm platform.
Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Replace the OVMF-specific SataControllerDxe (to be later removed) with
the generic, MdeModulePkg one, for OvmfPkg{Ia32, X64, Ia32X64} platforms.
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
ASSERT (Private != NULL) (where Private = CR(...)) is ineffective as
CR(Ptr, Type, Member, Sig) either returns Ptr - offsetof(Type, Member),
or ASSERTS on the signature, so it's unlikely to ever return NULL (must
be passed a pointer = member's offset, or in this case, 0x4).
ASSERT on This != NULL instead.
Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
When a UEFI_DRIVER attempts to open a protocol interface with BY_DRIVER
attribute that it already has open with BY_DRIVER attribute,
OpenProtocol() returns EFI_ALREADY_STARTED. This is not an error. The
UEFI-2.7 spec currently says,
> EFI_ALREADY_STARTED -- Attributes is BY_DRIVER and there is an item on
> the open list with an attribute of BY_DRIVER
> whose agent handle is the same as AgentHandle.
Downgrade the log mask for this one condition to DEBUG_INFO, in
SataControllerStart(). This will match the log mask of the other two
informative messages in this function.
(ported from commit 5dfba97)
Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
The ArmGicAcknowledgeInterrupt () returns the value returned by the
Interrupt Acknowledge Register and the InterruptID separately in an out
parameter.
The function documents the following: 'InterruptId is returned
separately from the register value because in the GICv2 the register
value contains the CpuId and InterruptId while in the GICv3 the register
value is only the InterruptId.'
This function skips setting the InterruptId in the out parameter for
GICv3. Although the return value from the function is the InterruptId
for GICv3, this breaks the function usage model as the caller expects
the InterruptId in the out parameter for the function. e.g. The caller
may end up using the InterruptID which could potentially be an
uninitialised variable value.
Therefore, set the InterruptID in the function out parameter for GICv3
as well.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
According to the GIC architecture version 3 and 4 specification, the
maximum number of INTID bits supported in the CPU interface is 24.
Considering this the RegShift variable is not required to be more than 8
bits. Therefore, make the RegShift variable type to UINT8. Also add
necessary typecasts when calculating the RegOffset and RegShift values.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
GICD_SGIR is a 32-bit register, of which INTID is bits [3:0] and Bits
[14:4] is RES0. Since SgiId parameter in the function ArmGicSendSgiTo ()
is UINT8, mask unused bits of SgiId before writing to the GICD_SGIR
register to prevent accidental setting of the RES0 bits.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
The IrqInterruptHandler () and ExitBootServicesEvent () function
declarations were unused. Therefore, remove these declarations.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
The EIOR register of the Gic CPU interface is a 32 bit register.
However, the HARDWARE_INTERRUPT_SOURCE used to represent the interrupt
source (Interrupt ID) is typedefed as UINTN, see
EmbeddedPkg\Include\Protocol\HardwareInterrupt.h
Therfore, typecast the interrupt ID (Source) value to UINT32 before
setting the EOIR register. Also, add an assert to check that the value
does not exceed 32 bits.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Although the maximum interrupt ID on GicV2 is 10bit and for GicV3/4 is
24bit, and that the IAR and EOIR registers of the Gic CPU interface are
32 bit; the typedef HARDWARE_INTERRUPT_SOURCE is defined as UINTN in
EmbeddedPkg\Include\Protocol\HardwareInterrupt.h
Therefore, use UINTN for Gic Interrupt variables and use appropriate
typecasts wherever needed.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
The CPU Interface Identification Register (GICC_IIDR) is a 32-bit
register. Since ArmGicGetInterfaceIdentification () returns the value
read from the GICC_IIDR register, update the return type for this
function to UINT32.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
According to edk2 coding standard specification, Non-Boolean comparisons
must use a compare operator (==, !=, >, < >=, <=). See Section 5.7.2.1
at https://edk2-docs.gitbook.io/
edk-ii-c-coding-standards-specification/5_source_files/ 57_c_programming
Therefore, fix the comparison in ArmGicEnableDistributor()
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
The Software Generated Interrupt Register (GICD_SGIR) is a 32 bit
register with the following bit assignment:
TargetListFilter, bits [25:24]
CPUTargetList, bits [23:16]
NSATT, bit [15]
SGIINTID, bits [3:0]
Therefore, modify the TargetListFilter, CPUTargetList, SGI Interrupt ID
parameters of the ArmGicSendSgiTo () to use UINT8 instead of INTN.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
The data type used by variables representing the
GicInterruptInterfaceBase has been inconsistently used in the ArmGic
driver and the library. The PCD defined for the GIC Interrupt interface
base address is UINT64. However, the data types for the variables used
is UINTN, INTN, and at some places UINT32.
Therefore, update the data types to use UINTN and add necessary
typecasts when reading values from the PCD. This should then be
consistent across AArch32 and AArch64 builds.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
The data type used by variables representing the GicDistributorBase has
been inconsistently used in the ArmGic driver and the library. The PCD
defined for the GIC Distributor base address is UINT64. However, the
data types for the variables used is UINTN, INTN, and at some places
UINT32.
Therefore, update the data types to use UINTN and add necessary
typecasts when reading values from the PCD. This should then be
consistent across AArch32 and AArch64 builds.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
In case a virtio serial device is found in the system register the first
console port as EFI console, by updating ConIn, ConOut and ErrOut.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
IsVirtioPciRng() becomes just a thin wrapper for IsVirtioPci().
This allows to add similar thin wrappers for other virtio
devices in the future.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
IsVirtioRng() becomes just a thin wrapper for IsVirtio().
This allows to add similar thin wrappers for other virtio
devices in the future.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
The #define for IMAGE_FILE_MACHINE_ARM is not present in MdePkg,
this looks like a relic not used any more. Remove.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
The BaseTools and MdePkg versions of PeImage.h diverged over time,
add some missing bits to the MdePkg header file in preparation for
removing the BaseTools version.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Appears to be a relic for ancient windows / compiler versions,
windows builds in CI work just fine without it.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Not needed any more on modern toolchains, they are better
in not creating a GOT without this trick.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Older linux kernels have problems with phys-bits larger than 46,
ubuntu 18.04 (kernel 4.15) has been reported to be affected.
Reduce phys-bits limit from 47 to 46.
Reported-by: Fiona Ebner <f.ebner@proxmox.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Flash can be write-protected in qemu (which is usually the case for
code). In case the variable store flash block is configured read-only
ovmf wouldn't be able to store EFI variables there, so not setting up
fvb in that case (and fallhack to emulation) is the better option.
It'll avoid problems later due to flash writes failing.
The patch tries to write back the original value read earlier, so flash
content doesn't change in case the write succeeds. But the status we
read back after the attempt to write will tell us whenever flash is
writable or not.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Apparently TPL_CALLBACK is too low, code runs into an ASSERT
complaining the new TPL is lower than the old TPL.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4424
In Relaxed-AP Sync Mode, BSP will not wait for all Aps arrive. However,
PerformRemainingTasks() needs to wait all Aps arrive before calling
SetMemMapAttributes and ConfigSmmCodeAccessCheck() when mSmmReadyToLock
is true. In SetMemMapAttributes(), SmmSetMemoryAttributesEx() will call
FlushTlbForAll() that need to start up the aps. So it need to let all
aps arrive. Same as SetMemMapAttributes(), ConfigSmmCodeAccessCheck()
also will start up the aps.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Zhihao Li <zhihao.li@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4431
In Ap relaxed mode, some SMI handlers should call SmmWaitForApArrival() to let all ap arrive in SmmCpuRendezvous(). But in traditional mode, these SMI handlers don't need to call SmmWaitForApArrival() again. So it need to be check cpu sync mode before calling SmmWaitForApArrival().
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Zhihao Li <zhihao.li@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
System paging 5 level enabled or not can be checked via CR4.LA57, system
preferred Page table Level (PcdUse5LevelPageTable) must align with previous
level for 64bit long mode.
This patch is to do the wise check:
If cpu has already run in 64bit long mode PEI, Page table Level in DXE
must align with previous level.
If cpu runs in 32bit protected mode PEI, Page table Level in DXE is decided
by PCD and feature capability.
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zeng Star <star.zeng@intel.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>
Background:
For arch X64, system will enable the page table in SPI to cover 0-512G
range via CR4.PAE & MSR.LME & CR0.PG & CR3 setting (see ResetVector code).
Existing code doesn't cover the higher address access above 512G before
memory-discovered callback. That will be potential problem if system
access the higher address after the transition from temporary RAM to
permanent MEM RAM.
Solution:
This patch is to migrate page table to permanent memory to map entire physical
address space if CR0.PG is set during temporary RAM Done.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zeng Star <star.zeng@intel.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>
Add a macro USE_5_LEVEL_PAGE_TABLE to determine whether to create
5 level page table.
If macro USE_5_LEVEL_PAGE_TABLE is defined, PML5Table is created
at (4G-12K), while PML4Table is at (4G-16K). In runtime check, if
5level paging is supported, use PML5Table, otherwise, use PML4Table.
If macro USE_5_LEVEL_PAGE_TABLE is not defined, to save space, 5level
paging is not created, and 4level paging is at (4G-12K) and be used.
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Debkumar De <debkumar.de@intel.com>
Cc: Catharine West <catharine.west@intel.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
In ResetVector, if create page table, its highest address is fixed
because after page table, code layout is fixed(4K for normal code,
and another 4K only contains reset vector code).
Today's implementation organizes the page table as following if 1G
page table is used:
4G-16K: PML4 page (PML4[0] points to 4G-12K)
4G-12K: PDP page
CR3 is set to 4G-16K
When 2M page table is used, the layout is as following:
4G-32K: PML4 page (PML4[0] points to 4G-28K)
4G-28K: PDP page (PDP entries point to PD pages)
4G-24K: PD page mapping 0-1G
4G-20K: PD page mapping 1-2G
4G-16K: PD page mapping 2-3G
4G-12K: PD page mapping 3-4G
CR3 is set to 4G-32K
CR3 doesn't point to a fixed location which is a bit hard to debug at
runtime.
The new page table layout will always put PML4 in highest address
When 1G page table is used, the layout is as following:
4G-16K: PDP page
4G-12K: PML4 page (PML4[0] points to 4G-16K)
When 2M page table is used, the layout is as following:
4G-32K: PD page mapping 0-1G
4G-28K: PD page mapping 1-2G
4G-24K: PD page mapping 2-3G
4G-20K: PD page mapping 3-4G
4G-16K: PDP page (PDP entries point to PD pages)
4G-12K: PML4 page (PML4[0] points to 4G-16K)
CR3 is always set to 4G-12K
So, this patch can improve debuggability by make sure the init
CR3 pointing to a fixed address(4G-12K).
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: Debkumar De <debkumar.de@intel.com>
Cc: Catharine West <catharine.west@intel.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
This patch only renames macro, with no code logic impacted.
Two purpose to rename macro:
1. Align some macro name in PageTables1G.asm and PageTables2M.asm, so
that these two files can be easily combined later.
2. Some Macro names such as PDP are not accurate, since 4 level page
entry also uses this macro. PAGE_NLE (no leaf entry) is better
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: Debkumar De <debkumar.de@intel.com>
Cc: Catharine West <catharine.west@intel.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4200
FspData->PerfIdx is getting increased for every call unconditionally
in the function SetFspMeasurePoint and hence memory access can happen
for out of bound FspData->PerfData[] array entries also.
Example -
FspData->PerfData is an array of 32 UINT64 entries. Assume a call
is made to SetFspMeasurePoint function when the FspData->PerfIdx
last value is 31. It gets incremented to 32 at line 400.
Any subsequent call to SetFspMeasurePoint functions leads to
FspData->PerfData[32] getting accessed which is out of the PerfData
array as well as the FSP_GLOBAL_DATA structure boundary.
Hence keep array access and index increment inside if block only and
return invalid performance timestamp when PerfIdx is invalid.
Cc: Chasel Chiu <chasel.chiu@intel.com>
Cc: Nate DeSimone <nathaniel.l.desimone@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Signed-off-by: Ranbir Singh <rsingh@ventanamicro.com>
Acked-by: Pedro Falcato <pedro.falcato@gmail.com>
Reviewed-by: Chasel Chiu <chasel.chiu@intel.com>
Fix incorrect value type issue for checked-box op-code.
When the variable for checked-box is defined as UINT8 in
varstore structure, IFR compiler assign its value type to
EFI_IFR_TYPE_NUM_SIZE_8 instead of EFI_IFR_TYPE_BOOLEAN.
However, the value type for checked-box is boolean value.
Redfish service may return error because of incorrect value
type passed to BIOS attribute registry.
Signed-off-by: Nickle Wang <nicklew@nvidia.com>
Cc: Abner Chang <abner.chang@amd.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
The DXE core implementation of PcdDxeNxMemoryProtectionPolicy already
contains an assertion that EfiConventionalMemory and EfiBootServicesData
are subjected to the same policy when it comes to the use of NX
permissions. The reason for this is that we may otherwise end up with
unbounded recursion in the page table code, given that allocating a page
table would then involve a permission attribute change, and this could
result in the need for a block entry to be split, which would trigger
the allocation of a page table recursively.
For the same reason, a shortcut exists in ApplyMemoryProtectionPolicy()
where, instead of setting the memory attributes unconditionally, we
compare the NX policies and avoid touching the page tables if they are
the same for the old and the new memory types. Without this shortcut, we
may end up in a situation where, as the CPU arch protocol DXE driver is
ramping up, the same unbounded recursion is triggered, due to the fact
that the NX policy for EfiConventionalMemory has not been applied yet.
To break this cycle, let's remap all EfiConventionalMemory regions
according to the NX policy for EfiBootServicesData before exposing the
CPU arch protocol to the DXE core and other drivers. This ensures that
creating EfiBootServicesData allocations does not result in memory
attribute changes, and therefore no recursion.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Map the code flash with read-only attributes so we can execute from it
even under a memory protection regime that enables WXN, making all
writable memory regions non-executable by default.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
The VariableRuntimeDxe links with NvVarStoreFormattedLib which is
required to establish the dependency on OvmfPkg\VirtNorFlashDxe.
The VirtNorFlashDxe installs the gEdkiiNvVarStoreFormattedGuid to
indicate it has finished initialising the flash variable storage
and that the variable service can be dispatched.
However, the kvmtool guest firmware dynamically detects if CFI
flash is absent and sets PcdEmuVariableNvModeEnable to TRUE
indicating emulated runtime variable must be used. Therefore,
in this scenario install the gEdkiiNvVarStoreFormattedGuid so
that the variable service can be dispatched.
Also link the NorFlashKvmtoolLib as a NULL library so that
it can discover if the CFI flash is absent and setup the PCD
PcdEmuVariableNvModeEnable. This is required in case the
NorFlashDxe is not yet dispatched.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
The kvmtool option '--flash <flash filename>' is used to launch
a guests VM with a CFI flash device that maps the flash file
specified at the command line.
However, kvmtool allows guest VMs to be launched without a CFI
flash device. In such scenarios the firmware can utilize the
emulated variable storage for UEFI variables. To support this
the PCD gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvModeEnable
must be set to TRUE.
Therefore, update the NorFlashKvmtoolLib to fallback to variable
emulation if a CFI device is not detected. Also improve the error
logging.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Kvmtool allows guest VMs to be launched with or without a
CFI flash device.
When the kvmtool option '--flash <flash filename>' is used to
launch a guest VM a CFI flash device maps the flash file that
was specified at the command line. The NorFlash driver uses
this flash as the variable storage backend.
However, when the above option is not specified, a CFI flash
device is not present. In such cases, the firmware can fallback
to use emulated runtime variables (which uses the VMs DRAM as
the storage backend).
Therefore, define the PCD PcdEmuVariableNvModeEnable required
to enable the emulated runtime variable support, but do not
enable it by default.
The firmware is expected to dynamically discover if the CFI
flash is present and subsequently enable NorFlash or emulate
the runtime variables.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
The PCD gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvModeEnable
indicates if a variable driver will emulate the variable NV mode.
This PCD is defined as [PcdsFixedAtBuild, PcdsPatchableInModule,
PcdsDynamic, PcdsDynamicEx].
Some firmware builds may define this PCD as a dynamic PCD and
initialise the value at runtime. Therefore, move the PCD declaration
from the [FixedPcd] section to the [Pcd] section in the platform
boot manager library file PlatformBootManagerLib.inf. Without this
change the build would not succeed.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
The patch "f07a9df9af60 ArmVirtPkg: Enable stack guard"
enabled stack overflow detection for ArmVirtPkg. Following
this patch, running UEFI shell command 'dmpstore' resulted
in a crash indicating a stack overflow. Invoking 'dmpstore'
results in recursive calls to CascadeProcessVariables ()
which apparently consumes the available stack space and
overflows.
Normally, SEC and PEI run off the initial stack, and the
DxeIpl PEIM is in charge of launching the DxeCore with a
full-sized stack and remapping it non-executable as well.
PrePi platforms take some shortcuts and the DXE and BDS
run off the initial stack which is relatively small. It
is therefore desirable to allocate 128 KiB worth of boot
services data memory as the stack for the Dxe phase.
The PrePiMain () in ArmVirtPkg/PrePi/PrePi.c invokes the
LoadDxeCoreFromFv () to load the Dxe core and transfers
control. The second parameter to LoadDxeCoreFromFv () is
the stack size, which is currently set to 0.
LoadDxeCoreFromFv () is implemented in PrePiLib and if the
stack size is 0, it continues to use the initial stack.
However, if a stack size is specified in the call to
LoadDxeCoreFromFv (), memory is allocated for a new stack
and the stack is switched to use the newly allocated stack
for the Dxe phase.
Therefore, specify 128 KiB as the stack size in the call to
LoadDxeCoreFromFv () so that a separate stack is allocated
and used for the Dxe phase.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4463
When the AARCH64 CpuDxe attempts to SyncCacheConfig() with the GCD, it
collects the page attributes as:
EntryAttribute = Entry & TT_ATTR_INDX_MASK
However, TT_ATTR_INDX_MASK only masks the cacheability attributes and
drops the memory protections attributes. Importantly, it also drops the
TT_AF (access flag) which is now wired up in EDK2 to represent
EFI_MEMORY_RP, so by default all SystemMem pages will report as
EFI_MEMORY_RP to the GCD. The GCD currently drops that silently, because
the Capabilities field in the GCD does not support EFI_MEMORY_RP by
default.
However, some ranges may support EFI_MEMORY_RP and incorrectly mark
those ranges as read protected. In conjunction with another change on
the mailing list (see: https://edk2.groups.io/g/devel/topic/98505340),
this causes an access flag fault incorrectly. See the linked BZ below
for full details.
This patch exposes all memory protections attributes to the GCD layer so
it can correctly set pages as EFI_MEMORY[RP|XP|RO] when it initially
syncs.
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Taylor Beebe <t@taylorbeebe.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
If PcdUse1GPageTable is not enabled restrict the physical address space
used to 1TB, to limit the amount of memory needed for identity mapping
page tables.
The same already happens in case the processor has no support for
gigabyte pages.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Flip the default for IO address space reservations for PCI(e) bridges
and root ports with hotplug support from TRUE to FALSE.
PCI(e) bridges will still get IO address space assigned in case:
(a) Downstream devices actually need IO address space, or
(b) Explicit configuration, using "qemu -device
pcie-root-port,io-reserve=<size>".
In case IO address space is exhausted edk2 will stop assigning resources
to PCI(e) bridges. This is not limited to IO resources, the affected
bridges will not get any memory resources assigned either.
This patch solves this issue by not handing out the scarce IO address
space, which is not needed in most cases anyway. Result is a more
consistent PCI configuration in virtual machine configurations with many
PCie root ports.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
When calling SetValue() with string type input, there is
assertion of providing zero string ID to HII string function.
Fix this issue by creating string ID for input string buffer.
Fix Unicode and Ascii code convert issue together.
Add text op-code support
Signed-off-by: Nickle Wang <nicklew@nvidia.com>
Cc: Abner Chang <abner.chang@amd.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
Reviewed-by: Igor Kulchytskyy <igork@ami.com>
RTC runtime is unable to get dynamic PCD value after booting to
OS using runtime services.
Resolution: Cache the dynamic PCD value in RTC driver entry point
Cc: Ray Ni <ray.ni@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Gua Guo <gua.guo@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Ideally behavior is like below order that can support one local build
machine, clone multiple Edk2, some of edk2 repo use old tag and
some of edk2 repo use new tag, they can both support on one machine.
1. if defined PYTHON_COMMAND only
- use PYTHON_COMMAND = user assigned
2. if not defined PYTHON_COMMAND, auto detect py -3
- use PYTHON_COMMAND = py -3
3. if defined PYTHON_COMMAND and PYTHON_HOME, use PYTHON_COMMAND
- use PYTHON_COMMAND = user assigned
4. if defined PYTHON_HOME only,
- use PYTHON_COMMAND = %PYTHON_HOME%/python.exe
SCRIPT_ERROR should return for paraent batch file to consume
for error handle.
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: Rebecca Cran <rebecca@bsdio.com>
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
1541 changed files with 304651 additions and 69457 deletions
// Maximum number of characters to print to serial (UINT8s) and to console if
// available (as UINT16s)
//
#define MAX_PRINT_CHARS 100
STATICCHAR8*gExceptionTypeString[]={
STATICCHAR8*gExceptionTypeString[]={
"Synchronous",
"Synchronous",
"IRQ",
"IRQ",
@@ -188,18 +194,14 @@ DefaultExceptionHandler (
INOUTEFI_SYSTEM_CONTEXTSystemContext
INOUTEFI_SYSTEM_CONTEXTSystemContext
)
)
{
{
CHAR8Buffer[100];
CHAR8Buffer[MAX_PRINT_CHARS];
CHAR16UnicodeBuffer[MAX_PRINT_CHARS];
UINTNCharCount;
UINTNCharCount;
INT32Offset;
INT32Offset;
if(mRecursiveException){
if(mRecursiveException){
STATICCHAR8CONSTMessage[]="\nRecursive exception occurred while dumping the CPU state\n";
STATICCHAR8CONSTMessage[]="\nRecursive exception occurred while dumping the CPU state\n";
SerialPortWrite((UINT8*)Message,sizeofMessage-1);
SerialPortWrite((UINT8*)Message,sizeofMessage-1);
if(gST->ConOut!=NULL){
AsciiPrint(Message);
}
CpuDeadLoop();
CpuDeadLoop();
}
}
@@ -207,9 +209,10 @@ DefaultExceptionHandler (
CharCount=AsciiSPrint(Buffer,sizeof(Buffer),"\n\n%a Exception at 0x%016lx\n",gExceptionTypeString[ExceptionType],SystemContext.SystemContextAArch64->ELR);
CharCount=AsciiSPrint(Buffer,sizeof(Buffer),"\n\n%a Exception at 0x%016lx\n",gExceptionTypeString[ExceptionType],SystemContext.SystemContextAArch64->ELR);
SerialPortWrite((UINT8*)Buffer,CharCount);
SerialPortWrite((UINT8*)Buffer,CharCount);
if(gST->ConOut!=NULL){
AsciiPrint(Buffer);
// Prepare a unicode buffer for ConOut, if applicable, in case the buffer
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.
