Part of the functions of the library are left unimplemented (return
EFI_UNSUPPORTED) the rest use information about current firmware
obtained from CBMEM (at this point available in a HOB) and SMMSTOREv2 to
perform flashing.
Flashing is slightly optimized: FmpDeviceSetImageWithStatus() first
reads a block and checks that it differs from the new contents before
initiating erase and write.
On successful flashing runtime APIs for dealing with EFI variables are
replaced with stubs to prevent accesses to SMMSTORE from the currently
running firmware. The SMMSTORE region's contents and possibly location
and size have been changed as a result of the update and continued use
of it can have unpredictable consequences including corruption of the
newly written firmware image. A capsule mode always ends with a reboot,
so the variable services are unavailable only for a very short period
after a successful flashing.
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
This is using test certificate stored in this repository. Building
additionally requires setting CAPSULE_FIRMWARE_GUID to firmware GUID in
string form.
FDF file is not updated because FMP driver is to be embedded into update
capsule.
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Make UefiPayloadPkg.dsc add required libraries/DXEs/PCDs when
CAPSULE_SUPPORT define is set to TRUE.
UefiPayloadEntry now parses firmware information from a bootloader and
switches boot mode to BOOT_ON_FLASH_UPDATE if there are any capsules.
It's not guarded by any PCD under the assumption that bootloader won't
pass capsules if EDK shouldn't be handling them.
EsrtDxe is enabled to manage ESRT entries and it consumes the firmware
information HOB created by UefiPayloadEntry. ProcessCapsules()
internally looks up EsrtManagementProtocol and calls SyncEsrtFmp() to
import data from available FMP instances.
PlatformBootManagerLib was made to call ProcessCapsules() twice: before
and after end-of-DXE.
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
When set to TRUE, bit EFI_OS_INDICATIONS_FMP_CAPSULE_SUPPORTED of
OsIndications is set.
At the moment EDK never sets this bit (there is only definition with no
uses), maybe nothing actually checks its value. Whatever the reason is,
it seems like a good idea to make setting it possible.
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
The implementation is for CbParseLib, SblParseLib returns success while
doing nothing.
The HOBs created by BuildCvHob() will be eventually picked up and
processed in DXE phase by
MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleProcessLib.c
Because multiple capsules can be chained (simply by placing them one
after another), coreboot passes them as a single memory range which can
provide tenths of capsules.
coreboot won't pass any capsules unless it finds CapsuleUpdateData*
EFI variables and is able to parse memory ranges they point to as
scatter-gather lists of pages containing capsules.
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Use firmware information passed by a bootloader and parsed by BlParseLib
to make a single-element ESRT. This informs operating systems and EDK
itself about which capsules are applicable for the current firmware.
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
The implementation is for CbParseLib, SblParseLib returns an error.
coreboot's CB_TAG_FW_INFO is a machine-friendly version of a system
firmware component. A component is identified by a GUID. This is meant
to be primarily a source of information for ESRT.
The following coreboot options translate directly into fields of the
structure with information:
- CONFIG_DRIVERS_EFI_MAIN_FW_GUID
- CONFIG_DRIVERS_EFI_MAIN_FW_VERSION
- CONFIG_DRIVERS_EFI_MAIN_FW_LSV
- CONFIG_ROM_SIZE
The first 3 options depend on CONFIG_DRIVERS_EFI_FW_INFO.
Version as a string depends on CONFIG_LOCALVERSION as well as version of
the code base (misnamed as KERNELVERSION in coreboot's build system).
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
They are used in SblParseLib.c (ParseSmbiosTable() and
ParseAcpiTableInfo() functions) but weren't declared as such.
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Commit f0a2015373 ("UefiPayloadPkg: Add AARCH64 support") changed
`[Components.X64]` to `[Components.X64, Components.AARCH64]` which
resulted in the following code within that section to not work as
expected (the code wasn't there, just providing a real world example
that uncovered the issue):
[Components.X64, Components.AARCH64]
FmpDevicePkg/FmpDxe/FmpDxe.inf {
...
<PcdsFixedAtBuild>
!include .../...PcdFmpDevicePkcs7CertBufferXdr.inc
...
}
At the same time `[Components.X64]` or even `[Components.AARCH64,
Components.X64]` (notice the swapped order) worked fine for X64 target.
The cause of the issue turned out to be skipping includes inside
`_PostProcess()` method of `DscParser` class. This method processes
list of items stored in a database filled on the first pass through a
DSC file in `Start()` method. One of the fields stored in each row
of a table is link to a parent object (owner). A section like
`[Components.X64, Components.AARCH64]` creates two objects and all of
its subelements are duplicated for both X64 and AARCH64. This was not
happening for !include statement in the example above.
Because `_PostProcess()` contracted a sequence of !include objects
disregarding their owner, it did not create instance for each of the
requested targets. Codewise, `self._ContentIndex` was incremented more
than once, while `__ProcessDirective()` method (invoked indirectly as
`Processer[self._ItemType]()`) queried owner of the current directive
as:
if self._InSubsection:
Owner = self._Content[self._ContentIndex - 1][8]
else: # not taken in this case
This is why order of targets made a difference, only the last was fully
initialized in this case.
An alternative fix is completely dropping merging of !include
directives, but hard to say whether it still has some utility (the code
is complex, hard to follow and barely documented). Safer to keep it, in
the worst case it doesn't do anything now.
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
When a BIOS implementation splits the PEIMs in multiple firmware volumes and
the FVs are reported to PEI Core by different PEIMs at different time,
it is hard to conclude the exact FV dispatch order.
The change updates the existing PEI dispatch logic to print the GUID of the
firmware volume and the FFS file which contains a nested FV.
It helps developers to match the FV being dispatched to the FV defined in
FDF file.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Currently a EFI_DEVICE_ERROR is returned if `TPM_RC_HANDLE` is the
return code from a TPM2_NV_ReadPublic command. However, in the TCG
TPM Library Part 3: Commands specification, `TPM_RC_HANDLE` is a
return code if:
1. An Index does not exist that corresponds to the handle
(TPM_RC_HANDLE)
2. The hierarchy associated with the existing NV Index is not
enabled (TPM_RC_HANDLE)
Therefore, return EFI_NOT_FOUND in this case, since that more
precisely allows a caller to identify this condition and act on
it as opposed to a more generic device error.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Tianocore uses a customized version of Uncrustify that previously
resided in https://dev.azure.com/projectmu/_git/Uncrustify.
An official fork in the Tianocore organization has been created
here https://github.com/tianocore/uncrustify.
The Tianocore fork publishes its releases to a GitHub release in
the repo. This is the first release from that repo:
https://github.com/tianocore/uncrustify/releases/tag/73.0.10
An advantage of this process is that the binaries for the release
are simply attached on the release page in a zip file.
For example, this is the zip file for that release:
https://github.com/tianocore/uncrustify/releases/download/73.0.10/uncrustify-release.zip
This eases consumption of the release, especially on non-Windows
hosts versus the previous distribution method with NuGet.
This change updates the external dependency in edk2 to consume the
binary from this zip file in the release of the Tianocore repo
instead of the previous NuGet feed in the Azure repo.
Note: The goal is to eliminate the Tianocore fork of Uncrustify, the
details for that are outside the scope of this commit.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Fix TestString() to be compatible with wide/narrow string in
GraphicsConsole driver. If WIDE_CHAR or NARROW_CHAR is hit in
TestString function, ignore it since OutputString function will
correctly handle it.
Fix OutputString() to skip wide/narrow char in TerminalDxe. Because
they are not displayable in terminal emulation tool, ingore to
output if they are hit in OutputString function.
Signed-off-by: Gao Qihang <gaoqihang@loongson.cn>
According to UEFI Spec, only Bit0...6 is valid in mode attribute, other
bits are undefined and must be 0. So attribute with EFI_WIDE_ATTRIBUTE
is unacceptable as EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL.SetAttribute() input
parameter. In current PrintInternal function, wide character removed
WIDE_CHAR, and is used as EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL.OutputString()
input parameter. So, wide character is mistakenly be treated as narrow
character.
Because EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL.OutputString() can handle unicode
string with NARROW_CHAR and WIDE_CHAR, we can directly invoke
OutputString() with whole unicode string in PrintInternal function instead
of separated wide/narrow string. And then, the logic of computing unicode
string width is also simplified.
Signed-off-by: Gao Qihang <gaoqihang@loongson.cn>
If string default is set to zero in vfr file and VfrCompile may not
found the invalid operation, assert is trigged. This patch will check
whether StringId is 0 to avoid assert.
Cc: Chao Li <lichao@loongson.cn>
Signed-off-by: Gao Qihang <gaoqihang@loongson.cn>
It's illegal that string default is numeric type in vfr string definition.
This patch add a check to the illegal behavior. If numeric string default
is encountered, throw a invalid parameter error to break VfrCompile.
Cc: Chao Li <lichao@loongson.cn>
Signed-off-by: Gao Qihang <gaoqihang@loongson.cn>
Commit dcde148 introduced EmbeddedPkg as a dependency
since gFdtTableGuid was in the EmbeddedPkg, but has now
been moved to MdePkg.
Signed-off-by: Prachotan Bathi <prachotan.bathi@arm.com>
Move Fdt Table Guid from EmbeddedPkg to MdePkg to avoid
unnecessary dependencies on EmbeddedPkg for packages like
ShellPkg. This change may affect modules dependent on
EmbeddedPkg but not on MdePkg, which is unlikely.
Also, per 8c721d6, MdePkg has a more refined implementation
of Fdt as compared to the EmbeddedPkg which was the initial
implementation.
Not moving gFdtVariableGuid since it'll be moved to platform
code.
Continuous-integration-options: PatchCheck.ignore-multi-package
Signed-off-by: Prachotan Bathi <prachotan.bathi@arm.com>
Since on UefiPayload the full PCI enumeration isn't run, the light
enumeration won't find Option ROMs. The introduced PciPlatform
driver relies on completed PCI enumeration and assumes that all
ROM bars have been properly assigned a free MMIO window.
Installs the gPciPlatformProtocol to scan for Option ROMs during
PCI enumeration light and copies found Option ROMs to runtime allocated
buffers. Only for work devices that have a ROMBAR, but doesn't for
devices that need a VBIOS loaded from SPI flash.
TEST: QEMU can enumerate Option ROMs on VGA and NIC on UefiPayloadPkg.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
This reverts commit ba6a8eb045.
PR https://github.com/tianocore/edk2/pull/11307 introduced a
logic change that caused regressions in FV verification on
some platforms. This PR is being reverted to restore the prior
logic.
The Code QL fixes in https://github.com/tianocore/edk2/pull/11307
can be resubmitted without the logic change along with one
commit for each type of Code QL issue being addressed.
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
As noted in the comment above the callback invocation,
the URB's callback may free the URB, so any
operations, including updates, must occur before the callback.
Signed-off-by: Sherry Fan <sherryfan@microsoft.com>
`XhcFreeUrb` attempts to unmap `Urb->DataMap` after
`FreePool(Urb->Data)` has already been called in some cases, causing a
use after free. Change the ordering so `Data` is freed after `Unmap`and
only freed when appropriate.
Signed-off-by: Sherry Fan <sherryfan@microsoft.com>
Add SkipHceReenable and SkipLinkStartup flags to
the EDKII_UFS_HC_PLATFORM_PROTOCOL to support
using a UFS controller that has already been
initialized.
Signed-off-by: Bob Morgan <bobm@nvidia.com>
Add arunsbaskaran as reviewer for SecurityPkg: Tcg related modules and
UefiCpuPkg.
Remove rahul1-kumar as reviewer from SecurityPkg: Tcg related modules
and UefiCpuPkg.
Signed-off-by: Arun Subramanian Baskaran <arun.subramanian.baskaran@intel.com>
The entrypoint module should do this programmatically using resources
passed by the bootloader. Under UPL, bootloaders are expected to pass
such ranges in the FDT.
Signed-off-by: Benjamin Doron <benjamin.doron@9elements.com>
This PPI is no longer used - the EHCI and XHCI host controller PEIMs
expose PEI_USB2_HOST_CONTROLLER_PPI instead.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
There are two versions of the USB host controller PPI, and only the
newer one, called PEI_USB2_HOST_CONTROLLER_PPI, is actually produced by
the EHCI and XHCI host controller PEIMs in EDK2. (The other PPI was only
produced by UhciPei which has been removed)
So remove all the conditionally executed code based on the distinction
between the two PPIs, and only support the newer one.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Remove the UHCI PEI module, which is unused (in edk2-platforms) and
obsolete. It also implements an older version of the USB host controller
PPI, which can be dropped from EDK2 entirely once this driver is gone.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Running Codeql on the MdeModulePkg\Bus\Usb drivers results in
codeql errors stemming for the following two checks.
- cpp/comparison-with-wider-type
- cpp/overflow-buffer
Signed-off-by: Aaron Pop <aaronpop@microsoft.com>
Co-authored-by: Michael Kubacki <michael.kubacki@microsoft.com>
Co-authored-by: Taylor Beebe <tabeebe@microsoft.com>
Co-authored-by: pohanch <125842322+pohanch@users.noreply.github.com>
Co-authored-by: kenlautner <85201046+kenlautner@users.noreply.github.com>
Co-authored-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Co-authored-by: Sean Brogan <sean.brogan@microsoft.com>
Co-authored-by: Aaron <aaronpop@microsoft>
Running Codeql on MdeModulePkg/Universal/Variable drivers results
in codeql errors stemming for the following two checks.
- cpp/comparison-with-wider-type
- cpp/overflow-buffer
- cpp/missing-null-test
Signed-off-by: Aaron Pop <aaronpop@microsoft.com>
Co-authored-by: Michael Kubacki <michael.kubacki@microsoft.com>
Co-authored-by: Taylor Beebe <tabeebe@microsoft.com>
Co-authored-by: pohanch <125842322+pohanch@users.noreply.github.com>
Co-authored-by: kenlautner <85201046+kenlautner@users.noreply.github.com>
Co-authored-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Co-authored-by: Sean Brogan <sean.brogan@microsoft.com>
Co-authored-by: Aaron <aaronpop@microsoft>
First, If there are multiple devices in DeviceList and are going to
remove the first device in the DeviceList, the DeviceList will be
cleared up with setting to NULL.
This is not the expected behavior, as it should keep the rest of the
devices in the DeviceList. DeviceList should point to the next device,
Dev->Next.
Second, there is a potential infinite while loop if TmpDev->Next not
equal to Dev. TmpDev should point to next device.
Signed-off-by: Hunter Chang <hunter.chang@intel.com>
Fedora 40, which is currently used as the base image for
the Linux jobs in the CI, is EOL.
Switch over to the Fedora 41 image (gcc 14).
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Add initial unit test for DxeImageVerificationHandler to
validate signature verification bypass for selected image types.
Signed-off-by: Alexander Gryanko <xpahos@gmail.com>
Currently when building NOOPT tests in MSVC, the linker cannot
pick the correct tolower for the host runtime. A small
workaround to make the build work in MSVC.
Signed-off-by: Alexander Gryanko <xpahos@gmail.com>
Added Google Mock test support for DevicePathLib.
Added OpenProtocol and CloseProtocol for UefiBootServicesTableLib
mock library.
Signed-off-by: Alexander Gryanko <xpahos@gmail.com>
MmCore ImageSize may be not page aligned, it will be converted to page
aligned for allocating MMRAM to hold MmCore image.
This patch is to call CreatMmHobList() with page aligned size of ImageSize,
otherwise ASSERT (IS_ALIGNED (Length, EFI_PAGE_SIZE)) in
MmIplBuildMmCoreModuleHob() will happen if the input MmCore ImageSize is
not page aligned.
Signed-off-by: Star Zeng <star.zeng@intel.com>
UefiDevicePathLib.inf consumes Boot Services in
MdePkg/Library/UefiDevicePathLib/DevicePathUtilitiesDxeSmm.c
- DevicePathFromHandle().
And so cannot be used by MM_STANDALONE drivers.
Instead, MM_STANDALONE drivers can use UefiDevicePathLibBase.inf
as the DevicePathLib of choice.
Cc: Sachin Ganesh <sachinganesh@ami.com>
Signed-off-by: Gowtham M <gowthamm@ami.com>
The file UefiDevicePathLibStandaloneMm.inf was reintroduced in [#3187] to
give downstream platforms time to transition to UefiDevicePathLibBase.inf
As nearly three years have passed since that change,
and downstream consumers have had sufficient time to migrate,
this library can now be safely removed.
Cc: Sachin Ganesh <sachinganesh@ami.com>
Signed-off-by: Gowtham M <gowthamm@ami.com>
As part of this PR [#3187],
MM_STANDALONE drivers should now map DevicePathLib to
UefiDevicePathLibBase.inf instead of UefiDevicePathLibStandaloneMm.inf,
as latter is being deprecated.
Cc: Sachin Ganesh <sachinganesh@ami.com>
Signed-off-by: Gowtham M <gowthamm@ami.com>
The ramdisk is modelled as an NVDIMM which have a naturally higher
alignment than 4K. Operating systems may wish to map NVDIMMs using large
pages, so force the allocation alignment to 2MB.
This change was tested using HTTP ramdisk boot, targeting a flat windows
image.
Signed-off-by: Aaron Pop <aaronpop@microsoft.com>
Mbedtls requires the use of strpbrk(), but it is currently
included in BaseCryptLib, which is not part of
BaseCryptLibMbedTls. To resolve this, add strpbrk() to
CrtWrapper.c, as BaseCryptLibMbedTls is not dependent
on OpensslLib.
Signed-off-by: HemaAnmisha <hema.anmisha.kalavakolanu@intel.com>
Mitigates CVE-2025-3770
Do not assume that IDT.limit is loaded with a zero value upon SMM entry.
Delay enabling Machine Check Exceptions in SMM until after the SMM IDT
has been reloaded.
Signed-off-by: John Mathews <john.mathews@intel.com>
