PcdStatusCodeUseSerial can be the dynamic PCD, which can't be used
in MM drivers. So, defines gMmStatusCodeUseSerialHobGuid HOB to
indicate StatusCode is reported via serial port or not. The value
shall match with the PcdStatusCodeUseSerial.
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
- FMMT tool would use the "PATH" environment variable for locating
the required GUID tool.
- On Windows-like system, batch file not found in the "PATH" environment
variable when "shell=False".
- This issue required commands to include program extensions or
absolute paths.
- This patch sets "shell=True" to extend the support for batch files,
including scripts in BinWrappers under BaseTools.
- Converted input commands from lists to strings to ensure proper
argument interpretation in POSIX-like shell scripts.
Signed-off-by: Jason1 Lin <jason1.lin@intel.com>
The values of BootRecordDataPayloadSize and CommSize are incorrect.
BootRecordDataPayloadSize should equal to
SmmBootRecordDataSize - SmmBootRecordDataRetrieved
CommSize should equal to
OFFSET_OF (EFI_MM_COMMUNICATE_HEADER,Data) \
+ (UINTN)MmCommBufferHeader->MessageLength
SmmCommData->BootRecordSize should be set to BootRecordDataPayloadSize,
instead of the total size of entire Smm boot record data.
Signed-off-by: Wei6 Xu <wei6.xu@intel.com>
In case of the FV with VTF, the left size should be enough to add the
minimum pad file size (EFI_FFS_FILE_HEADER, 0x18). It prevents the build
error, "GenFv: ERROR 0006: invalid FFS file header checksum" caused by the
pad file overwriting some header data in VTF. This includes these updates
for CalculateFvSize() function.
1. If NumBlocks is not defined, ensure the minimum pad file size for the
left size (if the pad file is required as VTF is not bottom aligned at end
of block, insert EFI_FFS_FILE_HEADER to ensure the pad file size)
2. If NumBlocks is defined, report more clear error message (the required
fv image size = 0x%x. the set fv image size = 0x%x. Free space left is not
enough to add a pad file (0x18))
3. Remove MaxPadFileSize, which is reported when the taken size is same as
the total size. It can not be the actual left size to add an FFS file. It
causes confusion when referring to the build log (FV Space Information)
Signed-off-by: Phil Noh <Phil.Noh@amd.com>
Adds a new library instance to support logging performance data in
Standalone MM.
- Add StandaloneMmPerformanceLib instance
- Move common MM logic to a new file `SmmPerformanceLibInternal.c`
- Since the library largely defers most logic to the performance
measurement protocol a large degree of code can be shared between
Standalone MM and Traditional MM.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Adds a new library instance to support MM core functionality for
performance in Standalone MM.
- Add StandaloneMmCorePerformanceLib instance
- Move common MM logic to a new file `MmCorePerformanceLib.c`
- Define interfaces with implementation specific to MM environment
type in `SmmCorePerformanceLibInternal.h` and implement those
functions in the Standalone MM and Traditional MM specific C files
Note: StandaloneMmCorePerformanceLib supports both
`MM_CORE_STANDALONE` and `MM_STANDALONE` as some Standalone MM
environments have privilege separation and need to link this
functionality in a ring 3 Standalone MM driver that is outside
the ring 0 Standalone MM core driver.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Refactor the file to use the new type name EFI_MM_COMMUNICATE_HEADER.
This is the same type but follows the new name and is more clear
with upcoming Standalone MM support being added.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
There will be build failure because of EFI_AP_PROCEDURE definition
not found if MpInformation2.h is included by base type library.
MpInformation2.h depends on MpService.h because of
EFI_PROCESSOR_INFORMATION definition, and then MpService.h
depends on PiMultiPhase.h because of EFI_AP_PROCEDURE definition.
This patch updates MpInformation2.h to include PiMultiPhase.h instead
of PiPei.h and also removes SecPlatformInformation.h including.
It also does minor refinement to file header description.
Signed-off-by: Star Zeng <star.zeng@intel.com>
The structure for the SPCR revision 4 table was originally named
EFI_ACPI_4_0_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE. This prefix suggests it
is an ACPI 4.0 structure, which it is not. This could cause confusion with
genuine ACPI 4.0 structures and defines (eg
EFI_ACPI_4_0_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE_SIGNATURE, which is
unrelated to SPCR revision 4).
Rename the structure to EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE_4.
Signed-off-by: Sarah Walker <Sarah.Walker2@arm.com>
Since OVMF would initialize the platform info with FwCfg,
TDVF needs to cache and measure the FwCfg at first.
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Elena Reshetova <elena.reshetova@intel.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
Signed-off-by: Ceping Sun <cepingx.sun@intel.com>
Since OVMF would initialize the platform info with FwCfg,
TDVF needs to cache and measure the FwCfg at first.
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Elena Reshetova <elena.reshetova@intel.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
Signed-off-by: Ceping Sun <cepingx.sun@intel.com>
Move QemuFwCfgSupported and QemuFwCfgDmaSupported to the struct
since they will be used as global variables in the DXE phase
along with QEMU_FW_CFG_CACHE_WORK_AREA.
Additionally, change its name to QEMU_FW_CFG_WORK_AREA.
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Elena Reshetova <elena.reshetova@intel.com>
Signed-off-by: Ceping Sun <cepingx.sun@intel.com>
OVMF uses FW_CFG_SELECTOR(0x510) and FW_CFG_IO_DATA(0x511) to
get configuration information from QEMU. From the security perspective
these information shall be measured before they're consumed.
This patch reads the FwCfg items and caches them in a GuidHob. In the
meanwhile these FwCfg items are measured as well. This is to avoid
changing the order when reading the FwCfg process, which depends on
multiple factors(depex, order in the Firmware volume).
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Elena Reshetova <elena.reshetova@intel.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
Signed-off-by: Ceping Sun <cepingx.sun@intel.com>
Since TDVF needs to cache and measure FwCfg, it is required to
add an API to support cache with optional measurement and add some
internal interfaces to support cache in QemuFwCfgLib.
The new API is listed below:
QemuFwCfgInitCache()
The new Internal interfaces are listed below:
InternalQemuFwCfgCacheReadBytes()
InternalQemuFwCfgCacheSelectItem()
InternalQemuFwCfgCacheGetWorkArea()
InternalQemuFwCfgCacheResetWorkArea()
InternalQemuFwCfgItemCached()
InternalQemuFwCfgCacheReading()
InternalQemuFwCfgInitCache()
InternalQemuFwCfgCheckOvmfWorkArea()
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Elena Reshetova <elena.reshetova@intel.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
Signed-off-by: Ceping Sun <cepingx.sun@intel.com>
Since the QEMU_FW_CFG_WORK_AREA is saved in EFI_HOB_PLATFORM_INFO
and InitializePlatform would read by QemuFwCfg, TDVF should build
the PlatformInfoHob before InitializePlatform.
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Elena Reshetova <elena.reshetova@intel.com>
Signed-off-by: Ceping Sun <cepingx.sun@intel.com>
Add QEMU_FW_CFG_CACHE_WORK_AREA in EFI_HOB_PLATFORM_INFO
to support reading from cache in QemuFwCfgLib.
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Elena Reshetova <elena.reshetova@intel.com>
Signed-off-by: Ceping Sun <cepingx.sun@intel.com>
Since TDVF has to measure FwCfg data from QEMU,
it is required to cache the data with measurement
in early phase. This can avoid changing the measurement
order when reading the FwCfg process, which depends
on multiple factors(depex, order in the firmware volume).
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Elena Reshetova <elena.reshetova@intel.com>
Signed-off-by: Ceping Sun <cepingx.sun@intel.com>
Add the SecTpmMeasurementLib to support
TpmMeasurementAndLogData in Sec phase.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
Signed-off-by: Ceping Sun <cepingx.sun@intel.com>
UefiPayloadPkg is used by non-UEFI bootloaders, e.g. coreboot.
Shuo works on Xeon-SP coreboot and will contribute to the
reviewing activity for UefiPayloadPkg.
Signed-off-by: Shuo Liu <shuo.liu@intel.com>
Building VarCheckHiiLib fails on my clang 19.1.6 setup with the error
variable 'Status' is used uninitialized whenever 'if' condition is false
due to the DispatchHandle != NULL test.
Calling this function with a NULL handle makes no sense, so move the test
to the function entry and return failure if appropriate.
Signed-off-by: Leif Lindholm <leif.lindholm@oss.qualcomm.com>
The doxygen comment for VarCheckHiiLibReceiveHiiBinHandler says that
EFI_INVALID_PARAMETER should be returned if either of CommBuffer or
CommBufferSize is NULL, but the test results in an early return of
EFI_SUCCESS.
Update the code to match the documentation.
Signed-off-by: Leif Lindholm <leif.lindholm@oss.qualcomm.com>
Add and install a protocol notification handler for
gEfiDxeMmReadyToLockProtocolGuid, in order to to trigger MMI
handler to install gEfiMmReadyToLockProtocolGuid protocol in Mm.
Signed-off-by: Crystal Lee <CrystalLee@ami.com>
When a USB device is enumerated it will report one or more endpoint
descriptors which contains a bInterval field which specifies the
interval a host should periodically poll for that particular endpoint
when scheduling transfers. But the units this value is expressed in
(in whole ms, a power of 2 x 1ms, or a power of 2 x 125us) may differ
depending on the speed of the device and whether the endpoint is
isochronous or interrupt.
Some high/super-speed devices, which are supposed to report isoc/int
bInterval as a power of 2 x 125us, incorrectly report full-speed
bInterval values (that is, in whole units of ms) in their interrupt
endpoint descriptors which results in an assertion error due to being
out of range of the spec-expected values. Rather than asserting, try
to adjust those assuming they were expressed in units of ms with an
upper limit of 128ms.
Signed-off-by: Jack Pham <jackp@qti.qualcomm.com>
Currently the bInterval value must be calculated differently
based on whether the endpoint type is isochronous or interrupt,
and whether the device is low, full, high or super speed. Plus,
this is duplicated for both XhcInitializeEndpointContext() and
XhcInitializeEndpointContext64().
To reduce code complexity and duplication, and for future ease of
maintenance, factor this logic out to a separate CalculateInterval()
helper function.
Signed-off-by: Jack Pham <jackp@qti.qualcomm.com>
Used SafeUint32Add to calculate and validate OutTransferLength with
boundary check in IScsiOnR2TRcvd to avoid integer overflow
Signed-off-by: Madhavan <madavtechy@gmail.com>
Since TdxMeasurementLib has been moved to MdeModulePkg,
the duplicate code should be removed.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Ceping Sun <cepingx.sun@intel.com>
Since the TdxMeasurementLib has been moved from UefiCpuPkg to MdeModulePkg,
the [Packages] section in .INF file shall be updated accordingly.
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Elena Reshetova <elena.reshetova@intel.com>
Signed-off-by: Ceping Sun <cepingx.sun@intel.com>
There are 2 reasons to move TdxMeasurementLib LibraryClass from
UefiCpuPkg to MdeModulePkg:
1. TpmMeasurementLib.h is located at MdeModulePkg/Include/Library.
It is similiar as TdxMeasurementLib.h.
2. TdxMeasurementLib is designed for TDX Measurement, it can be called
from SecurityPkg. And it is not much related to UefiCpuPkg.
Based upon above consideration, it's better to move TdxMeasurementLib
LibraryClass from UefiCpuPkg to MdeModulePkg.
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Min Xu <min.m.xu@intel.com>
Signed-off-by: Ceping Sun <cepingx.sun@intel.com>
Kvmtool always generates a PCI host device tree node. Thus PCI related
ACPI tables are always generated. Rely on the presence of PCI devices
in the interrupt-map information instead.
Reported-by: Sarah Walker <sarah.walker2@arm.com>
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
kvmtool advertises 4 serial ports. The DynamicTablesPkg advertises:
- the first port as the console port / SPCR table
- the second port as the debug port / DBG2 table
- the other ports are currently ignored
Advertise the last 2 serial port to the OS by describing them in SSDT
tables. New serial devices can be seen at:
Before patch:
$ ls /sys/devices/pnp0
00:00 00:01 00:02 power uevent
After patch:
$ ls /sys/devices/pnp0
00:00 00:01 00:02 00:03 00:04 power uevent
The EStdAcpiTableIdSsdtSerialPort entry is placed before the
last 3 PCI related tables as they might be dynamically removed
depending on kvmtool parameters.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Switch over to Tpm2InstanceLibDTpmSvsm as the Tpm2 implementation to
support vTPMs provided by an SVSM.
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
SEV-SNP provides a feature known as VM Privilege Level (VMPL), which
allows for services to be run in the guest at different privilege
levels. By running at VMPL0 (most privileged VM level), the SVSM can be
used to provide privileged services, e.g. a virtual TPM, for the guest
rather than trust such services from the hypervisor.
This patch adds a DTpm driver to communicate with a virtual TPM running
in the SVSM. The driver follows the vTPM protocol documented in the SVSM
specification.
SVSM vTPM functionality is available as new device and instance
libraries, which can be consumed optionally, keeping changes to the
regular TPM implementation minimal.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Co-authored-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Claudio Carvalho <cclaudio@linux.ibm.com>
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
A some of functions implemented in Tpm2Ptp.c are forward declared in a
couple of places. To clean this up, introduce a header that contains
these declarations in a central place and use it instead.
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Fix some spelling/grammar mistakes in the documentation comments.
Suggested-by: Dionna Glaze <dionnaglaze@google.com>
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
As described in the SVSM specification, guest components can call to the
SVSM vTPM through the vTPM protocol (protocol-id 2).
The SVSM vTPM protocol follows the Microsoft TPM Simulator interface
(MSSIM) and supports two services:
- SVSM_VTPM_QUERY (call-id 0): query MSSIM commands and vTPM features
supported.
- SVSM_VTPM_CMD (call-id 1): send a MSSIM command to be run by the vTPM
and get the result.
This patch adds support for SVSM_VTPM_QUERY and SVSM_VTPM_CMD to invoke
a SVSM when the guest is running at VMPL0.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Co-authored-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Claudio Carvalho <cclaudio@linux.ibm.com>
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Add call numbers for the SVSM vTPM protocol, as defined in the "Secure
VM Service Module for SEV-SNP Guests" Publication # 58019 Revision: 1.00
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
We need to stub the SVSM vTPM protocol in the UefiCpuPkg in order to
support a SEV-SNP guest running under a SVSM at VMPL1 or lower.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Co-authored-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Claudio Carvalho <cclaudio@linux.ibm.com>
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Periodically, mergify rebase operations will fail because
an account is selected to perform the rebase that does
not have permissions to do the rebase.
Insetad, use the tianocore-issues account to perform the
rebase operation.
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
For AARCH64 using StandaloneMmPkg, gMmCommBufferHobGuid will not exist.
Aarch64 makes use of their own Root MmiHandler that will get the
communication buffer out of a separate buffer, and will call
MmiMange directly with the information.
For x64, where gMmCommBufferHobGuid is expected to be supplied
in the hob list passed to StandaloneCore, if the hob does not
exist, print out a debug message describing the failure scenario.
Its important to note that a mising gMmCommBufferHobGuid will
mean non-root MmiHandlers will not be dispatched in the x64
scenario, but that root MmiHandlers will still be dispatched.
Signed-off-by: Aaron Pop <aaronpop@microsoft.com>
Co-authored-by: Aaron Pop <aaronpop@microsoft.com>
There are duplicate library function names between 2 Unit Test libraries
(UnitTestPeiServicesTablePointerLib and UnitTestUefiBootServicesTableLib).
There are 3 functions (UnitTestAllocatePages, UnitTestAllocatePool and
UnitTestFreePage). This update avoids the duplication and prevents a build
error when building a Unit Test application that links the libraries based
on UnitTestFrameworkPkg.
Signed-off-by: Phil Noh <Phil.Noh@amd.com>
Prior to this change, OVMF considers opt/ovmf/X-PciMmio64Mb the
minimum aperture size, allowing us to force the window to be larger
but not smaller than what PlatformDynamicMmioWindow calculates.
Adjust OVMF so that a smaller value for the aperture is honored.
Context:
Due to an inefficiency in the way older host kernels manage
pfnmaps for guest VM memory ranges [0], guests with large-BAR
GPUs passed-through have a very long (multiple minutes) initialization
time when the MMIO window advertised by OVMF is sufficiently sized for
the passed-through BARs (i.e., the correct OVMF behavior). However, on
older distro series such as Ubuntu Jammy, users have benefited from fast
guest boot times when OVMF advertised an MMIO window that was too small
to accommodate the full BAR, since this resulted in the long PCI initialization
process being skipped (and retried later, if pci=realloc pci=nocrs were set).
While the root cause is being fully addressed in the upstream kernel [1],
the solution relies on huge pfnmap support, which is a substantial series
with many ABI changes that is unlikely to land in many LTS and legacy distro kernels,
including those of Ubuntu Noble. As a result, the only kernel improvement
supported on those kernels is this patch [2], which reduces the extra boot
time by about half. Unfortunately, that boot time is still an average of
1-3 minutes longer per-VM-boot than what can be achieved when the host is
running a version of OVMF without PlatformDynamicMmioWindow (PDMW) support
(introduced in [3])
Since there is no way to force the use of the classic MMIO window size[4]
in any version of OVMF after [3], and since we have a use case for such
functionality on legacy distro kernels that would yield significant,
recurring compute time savings across all impacted VMs, this change to
this knob's behavior seems appropriate.
[0]: https://lore.kernel.org/all/CAHTA-uYp07FgM6T1OZQKqAdSA5JrZo0ReNEyZgQZub4mDRrV5w@mail.gmail.com/
[1]: https://lore.kernel.org/all/20250205231728.2527186-1-alex.williamson@redhat.com/
[2]: https://lore.kernel.org/all/20250111210652.402845-1-alex.williamson@redhat.com/
[3]: ecb778d
[4]: https://edk2.groups.io/g/devel/topic/109651206?p=Created,,,20,1,0,0
Signed-off-by: Mitchell Augustin <mitchell.augustin@canonical.com>
When FDT based DTB is parsed, variables mPciRootBridgeInfo and
mUplPciSegmentInfoHob are always dereferenced. If there is no PCI
RB Bridge info or RB Segment info provided in FDT, it leads to
NULL pointer dereferenced.
To address this issue, parse PCI RB and Segment information only
when they are available at FDT. If they are unavailable, skip it
and allow the PciBusDxe and PciHostBridgeDxe to handle them.
Signed-off-by: Ajan Zhong <ajan.zhong@newfw.com>
- In the commit 42a141800c
there was a misuse of "is_dir" method.
- Treating it as an object rather than function call,
which caused if-condition to always as "false".
- No files would be added to scanning list due to incorrect usage.
- This patch corrects the issue by properly using "is_dir()".
Signed-off-by: Jason1 Lin <jason1.lin@intel.com>
- This patch is intended to fix the debug macro issue reported from
the Debug Macro Checking.
- Remove the redundant comma between two debug message string.
Signed-off-by: Jason1 Lin <jason1.lin@intel.com>
Introduce gUiAppFileGuid: it has the same value of UiApp guid defined in
the .inf file. This is used to register UiApp as a boot entry in the
BootManagerMenu.
This registration is done in PlatformBootManagerBeforeConsole because
it must be done before the hotkeys are registered. This is because
in a system with hotkeys still bound to UiApp, but with firmware disabled,
you can still boot into the latter by hitting ESC or F2 during boot.
UiApp can be enabled/disabled using fw_cfg option FirmwareSetupSupport
Signed-off-by: Luigi Leonardi <leonardi@redhat.com>
Jiaxin Wu