TdxValidateCfv is used to validate the integrity of FlashNvVarStore
(PcdOvmfFlashNvStorageVariableBase) and it is not Tdx specific.
So it will be moved to PlatformInitLib and be renamed to
PlatformValidateNvVarStore in the following patch. And it will be called
before EmuVaribleNvStore is initialized with the content in
FlashNvVarStore.
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>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
In previous implementation below Pci related PCDs were set based on the
ResourceDescriptor passed in TdHob.
- PcdPciMmio64Base / PcdPciMmio64Size
- PcdPciMmio32Base / PcdPciMmio32Size
- PcdPciIoBase / PcdPciIoSize
The PCDs will not be set if TdHob doesn't include these information. This
patch set the PCDs with the information initialized in PlatformInitLib
by default. Then TdxDxe will check the ResourceDescriptor in TdHob and
reset them if they're included.
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>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3974
CcProbeLib once was designed to probe the Confidential Computing guest
type by checking the PcdOvmfWorkArea. But this memory is allocated with
either EfiACPIMemoryNVS or EfiBootServicesData. It cannot be accessed
after ExitBootService. Please see the detailed analysis in BZ#3974.
To fix this issue, CcProbeLib is redesigned as 2 implementation:
- SecPeiCcProbeLib
- DxeCcProbeLib
In SecPeiCcProbeLib we check the CC guest type by reading the
PcdOvmfWorkArea. Because it is used in SEC / PEI and we don't worry about
the issues in BZ#3974.
In DxeCcProbeLib we cache the GuestType in Ovmf work area in a variable.
After that the Guest type is returned with the cached value. So that we
don't need to worry about the access to Ovmf work area after
ExitBootService.
The reason why we probe CC guest type in 2 different ways is the global
varialbe. Global variable cannot be used in SEC/PEI and CcProbe is called
very frequently.
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>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3974
SecPeiCcProbeLib is designed to probe the Confidential Computing guest
type in SEC/PEI phase. The CC guest type was set by each CC guest at
the beginning of boot up and saved in PcdOvmfWorkArea.
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>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Increase the maximum line length for debug messages.
While log messages should be short, they can still
get quite long, for example when printing device paths
or config strings in HII routing.
512 chars is an empirically good value.
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
There's no bhyve specific PlatformSecureLib any more. Use the default
one of OvmfPkg which works too.
Signed-off-by: Corvin Köhne <c.koehne@beckhoff.com>
Reviewed-by: Ard Biesheuvel <ardb+tianocore@kernel.org>
In an effort to clean the documentation of the above
package, remove duplicated words.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Per the UEFI specification, if the Request argument in
EFI_HII_CONFIG_ACCESS_PROTOCOL.ExtractConfig() is NULL or does not contain
any request elements, the implementation should return all of the settings
being abstracted for the particular ConfigHdr reference.
The current implementation returns EFI_INVALID_PARAMETER if Request is
NULL or does not contain any request elements. Instead, construct
a new ConfigRequest to handle these cases per the specification.
In addition, per the UEFI specification, if the Configuration argument in
EFI_HII_CONFIG_ACCESS_PROTOCOL.RouteConfig() has a ConfigHdr that
specifies a non-existing target, the implementation should return
EFI_NOT_FOUND.
The current implementation returns EFI_INVALID_PARAMETER if Configuration
has a non-existing target in ConfigHdr. Instead, perform a check and
return EFI_NOT_FOUND in this case.
Signed-off-by: Dimitrije Pavlov <Dimitrije.Pavlov@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Per UEFI Spec 2.9, EFI_HII_CONFIG_ROUTING_PROTOCOL.RouteConfig()
should return EFI_INVALID_PARAMETER if caller passes in a NULL for
the Configuration parameter (see 35.4 EFI HII Configuration Routing
Protocol).
Add a check to return EFI_INVALID_PARAMETER when Configuration is NULL.
Signed-off-by: Yuan Yu <yuanyu@google.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Add BUILD_SHELL flag, similar to the one in OvmfPkg/AmdSev,
to enable/disable building of the UefiShell as part of
the firmware image. The UefiShell should not be included for
secure production systems (e.g. SecureBoot) because it can be
used to circumvent security features.
The default value for BUILD_SHELL is TRUE to keep the default
behavior of the Ovmf build.
Note: the default for AmdSev is FALSE.
The BUILD_SHELL flag for AmdSev was introduced in b261a30c90.
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
The current implementation does not check if Language or DriverName
are NULL. This causes the SCT test suite to crash.
Add a check to return EFI_INVALID_PARAMETER if any of these pointers
are NULL.
Signed-off-by: Dimitrije Pavlov <Dimitrije.Pavlov@arm.com>
Reviewed-by: Sunny Wang <sunny.wang@arm.com>
The current implementation does not check if Info or SizeInfo
pointers are NULL. This causes the SCT test suite to crash.
Add a check to return EFI_INVALID_PARAMETER if any of these
pointers are NULL.
Signed-off-by: Dimitrije Pavlov <Dimitrije.Pavlov@arm.com>
Reviewed-by: Sunny Wang <sunny.wang@arm.com>
The current implementation does not check if Progress or Results
pointers in ExtractConfig are NULL, or if Progress pointer in
RouteConfig is NULL. This causes the SCT test suite to crash.
Add a check to return EFI_INVALID_PARAMETER if any of these pointers
are NULL.
Signed-off-by: Dimitrije Pavlov <Dimitrije.Pavlov@arm.com>
Reviewed-by: Sunny Wang <sunny.wang@arm.com>
Ensure that the PixelInformation field of the
EFI_GRAPHICS_OUTPUT_MODE_INFORMATION structure is zeroed out in
EFI_GRAPHICS_OUTPUT_PROTOCOL.QueryMode() and
EFI_GRAPHICS_OUTPUT_PROTOCOL.SetMode() when PixelFormat is
PixelBlueGreenRedReserved8BitPerColor.
According to UEFI 2.9 Section 12.9, PixelInformation field of the
EFI_GRAPHICS_OUTPUT_MODE_INFORMATION structure is valid only if
PixelFormat is PixelBitMask. This means that firmware is not required
to fill out the PixelInformation field for other PixelFormat types,
which implies that the QemuVideoDxe implementation is technically
correct.
However, not zeroing out those fields will leak the contents of the
memory returned by the memory allocator, so it is better to explicitly
set them to zero.
In addition, the SCT test suite relies on PixelInformation always
having a consistent value, which causes failures.
Signed-off-by: Dimitrije Pavlov <Dimitrije.Pavlov@arm.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Fix path to follow naming convention of "AArch64", and allow the path
in "Maintainers.txt" to work as expected.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3982
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
The email addresses for the reviewers of the MptScsi and
PvScsi are no longer valid. Disable the MptScsi and PvScsi
drivers in all DSC files until new maintainers/reviewers can
be identified.
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: Sebastien Boeuf <sebastien.boeuf@intel.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
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>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
The new changes in SecureBootVariableLib brought in a new dependency of
PlatformPKProtectionLib.
This change added the new library instance from SecurityPkg to resolve
pipeline builds.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Rebecca Cran <rebecca@bsdio.com>
Cc: Peter Grehan <grehan@freebsd.org>
Cc: Sebastien Boeuf <sebastien.boeuf@intel.com>
Signed-off-by: Kun Qin <kuqin12@gmail.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Acked-by: Michael Kubacki <michael.kubacki@microsoft.com>
Include HardwareInfoLib classes in the IntelTdxX64.dsc for this
platform to use it during build given that PciHostBridgeUtilityLib
depends on it.
Cc: Alexander Graf <graf@amazon.de>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Nicolas Ojeda Leon <ncoleon@amazon.com>
Consume the host-provided specification of PCI host bridges if
available. Using the DxeHardwareInfoLib, populate a list of
hardware descriptors based on the content of the "hardware-info"
fw-cfg file, if provided. In the affirmative case, use the
resources and attributes specified by the hypervisor for each
Host Bridge to create the RootBridge elements.
In Ovmf platforms, the host can provide the specification of
non-discoverable hardware resources like PCI host bridges. If the
proper fw-cfg file is found, parse the contents provided by the
host into a linked list by using the Hardware Info library. Then,
using the list of PCI host bridges' descriptions, populate the
PCI_ROOT_BRIDGES array with the resources and attributes specified
by the host. If the file is not provided or no Host Bridge is found
in it, fold back to the legacy method based on pre-defined
apertures and rules.
In some use cases, the host requires additional control over the
hardware resources' configurations in the guest for performance and
discoverability reasons. For instance, to disclose information about
the PCI hierarchy to the guest so that this can profit from
optimized accesses. In this case, the host can decide to describe
multiple PCI Host Bridges and provide a specific set of resources
(e.g. MMIO apertures) so that the guest uses the values provided.
Using the provided values may entitle the guest to added performance,
for example by using specific MMIO mappings that can enable peer-to-peer
communication across the PCI hierarchy or by allocating memory closer
to a device for faster DMA transactions.
Cc: Alexander Graf <graf@amazon.de>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Nicolas Ojeda Leon <ncoleon@amazon.com>
Read the "hardware-info" item from fw-cfg to extract specifications
of PCI host bridges and analyze the 64-bit apertures of them to
find out the highest 64-bit MMIO address required which determines
the address space required by the guest, and, consequently, the
FirstNonAddress used to calculate size of physical addresses.
Using the static PeiHardwareInfoLib, read the fw-cfg file of
hardware information to extract, one by one, all the host
bridges. Find the last 64-bit MMIO address of each host bridge,
using the HardwareInfoPciHostBridgeLib API, and compare it to an
accumulate value to discover the highest address used, which
corresponds to the highest value that must be included in the
guest's physical address space.
Given that platforms with multiple host bridges may provide the PCI
apertures' addresses, the memory detection logic must take into
account that, if the host provided the MMIO windows that can and must
be used, the guest needs to take those values. Therefore, if the
MMIO windows are found in the host-provided fw-cfg file, skip all the
logic calculating the physical address size and just use the value
provided. Since each PCI host bridge corresponds to an element in
the information provided by the host, each of these must be analyzed
looking for the highest address used.
Cc: Alexander Graf <graf@amazon.de>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Nicolas Ojeda Leon <ncoleon@amazon.com>
Following the Hardware Info library, create the DxeHardwareInfoLib
which implements the whole API capable of parsing heterogeneous hardware
information. The list-like API grants callers a flexible and common
pattern to retrieve the data. Moreover, the initial source is a BLOB
which generalizes the host-to-guest transmission mechanism.
The Hardware Info library main objective is to provide a way to
describe non-discoverable hardware so that the host can share the
available resources with the guest in Ovmf platforms. This change
features and embraces the main idea behind the library by providing
an API that parses a BLOB into a linked list to retrieve hardware
data from any source. Additionally, list-like APIs are provided so
that the hardware info list can be traversed conveniently.
Similarly, the capability is provided to filter results by specific
hardware types. However, heterogeneous elements can be added to the
list, increasing the flexibility. This way, a single source, for
example a fw-cfg file, can be used to describe several instances of
multiple types of hardware.
This part of the Hardware Info library makes use of dynamic memory
and is intended for stages in which memory services are available.
A motivation example is the PciHostBridgeLib. This library, part
of the PCI driver populates the list of PCI root bridges during DXE
stage for future steps to discover the resources under them. The
hardware info library can be used to obtain the detailed description
of available host bridges, for instance in the form of a fw-cfg file,
and parse that information into a dynmaic list that allows, first to
verify consistency of the data, and second discover the resources
availabe for each root bridge.
Cc: Alexander Graf <graf@amazon.de>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Nicolas Ojeda Leon <ncoleon@amazon.com>
Define the HardwareInfoLib API and create the PeiHardwareInfoLib
which implements it, specifically for Pei usage, supporting
only static accesses to parse data directly from a fw-cfg file.
All list-like APIs are implemented as unsupported and only a
fw-cfg wrapper to read hardware info elements is provided.
The Hardware Info library is intended to describe non-discoverable
hardware information and share that from the host to the guest in Ovmf
platforms. The QEMU fw-cfg extension for this library provides a first
variation to parse hardware info by reading it directly from a fw-cfg
file. This library offers a wrapper function to the plain
QmeuFwCfgReadBytes which, specifically, parses header-data pairs out
of the binary values in the file. For this purpose, the approach is
incremental, reading the file block by block and outputting the values
only for a specific known hardware type (e.g. PCI host bridges). One
element is returned in each call until the end of the file is reached.
Considering fw-cfg as the first means to transport hardware info from
the host to the guest, this wrapping library offers the possibility
to statically, and in steps, read a specific type of hardware info
elements out of the file. This method reads one hardware element of a
specific type at a time, without the need to pre-allocate memory and
read the whole file or dynamically allocate memory for each new
element found.
As a usage example, the static approach followed by this library
enables early UEFI stages to use and read hardware information
supplied by the host. For instance, in early times of the PEI stage,
hardware information can be parsed out from a fw-cfg file prescinding
from memory services, that may not yet be available, and avoiding
dynamic memory allocations.
Cc: Alexander Graf <graf@amazon.de>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Nicolas Ojeda Leon <ncoleon@amazon.com>
Create the Hardware Info library base together with the specifics to
describe PCI Host Bridges.
The Hardware Info library is intended to be used for disclosing
non-discoverable hardware information from the host to the guest in
Ovmf platforms. Core functionality will provide the possibility to
parse information from a generic BLOB into runtime structures. The
library is conceived in a generic way so that further hardware
elements can also be described using it. For such purpose the length
of the BLOB is not restricted but instead regarded as a sequence of
header-info elements that allow the parsing during runtime. The first
type of hardware defined will be PCI host bridges, providing the
possibility to define multiple and specify the resources each of them
can use. This enables the guest firmware to configure PCI resources
properly. Having the size of each individual element favors the reuse
of a single interface to convey descriptions of an arbitrary number
of heterogenous hardware elements. Furthermore, flexible access
mechanisms coupled with the size will grant the possibility of
interpreting them in a single run.
Define the base types of the generic Hardware Info library to parse
heterogeneous data. Also provide the specific changes to support
PCI host bridges as the first hardware type supported by the
library.
Additionally, define the HOST_BRIDGE_INFO structure to describe PCI
host bridges along with the functionality to parse such information
into proper structures used by the PCI driver in a centralized manner
and taking care of versioning.
As an example and motivation, the library will be used to define
multiple PCI host bridges for complex platforms that require it.
The first means of transportation that will be used is going to be
fw-cfg, over which a stream of bytes will be transferred and later
parsed by the hardware info library. Accordingly, the PCI driver
will make use of these host bridges definitions to populate the
list of Root Bridges and proceed with the configuration and discovery
of underlying hardware components.
As mentioned before, the binary data to be parsed by the Hardware
Info library should be organized as a sequence of Header-element
pairs in which the header describes the type and size of the associated
element that comes right after it. As an illustration, to provide
inforation of 3 host bridges the data, conceptually, would look
like this:
Header PCI Host Bridge (type and size) # 1
PCI Host Bridge info # 1
Header PCI Host Bridge (type and size) # 2
PCI Host Bridge info # 2
Header PCI Host Bridge (type and size) # 3
PCI Host Bridge info # 3
Cc: Alexander Graf <graf@amazon.de>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Nicolas Ojeda Leon <ncoleon@amazon.com>
We can have multiple [LibraryClasses] sections, so we can place
all TPM-related library configuration to a single include file.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
It is an typo error that HobList pointer should be stored at
PcdOvmfWorkAreaBase, not PcdSevEsWorkAreaBase.
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>
This reverts commit ff36b2550f.
Has no effect because GCC_IA32_CC_FLAGS and GCC_X64_CC_FLAGS are unused.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
The ebp/rbp register can either be used for the frame pointer or
as general purpose register. With gcc (and clang) this depends
on the -f(no-)omit-frame-pointer switch.
This patch updates tools_def.template to explicitly set the compiler
option and also add a define to allow conditionally compile code.
The new define is used to fix stack switching in TemporaryRamMigration.
The ebp/rbp must not be touched when the compiler can use it as general
purpose register. With version 12 gcc starts actually using the
register, so changing it leads to firmware crashes in some
configurations.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3934
Reported-by: Jiri Slaby <jirislaby@kernel.org>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
The feature of SecMeasurementLibTdx is replaced by SecTpmMeasurementLibTdx
(which is in SecurityPkg). So SecMeasurementLibTdx is deleted.
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
MeasureHobList and MeasureFvImage once were implemented in
SecMeasurementTdxLib. The intention of this patch-set is to refactor
SecMeasurementTdxLib to be an instance of TpmMeasurementLib. So these
2 functions (MeasureHobList/MeasureFvImage) are moved to
PeilessStartupLib. This is because:
1. RTMR based trusted boot is implemented in Config-B (See below link)
2. PeilessStartupLib is designed for PEI-less boot and it is the right
place to do the measurement for Hoblist and Config-FV.
Config-B: https://edk2.groups.io/g/devel/message/76367
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>
Signed-off-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3853
Enable RTMR based measurement and measure boot for Td guest.
Cc: Brijesh Singh <brijesh.singh@amd.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>
Cc: Ken Lu <ken.lu@intel.com>
Cc: Sami Mujawar <sami.mujawar@arm.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>
RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3853
TdTcg2Dxe mimics the Security/Tcg/Tcg2Dxe. It does below tasks:
- Set up and install CC_EVENTLOG ACPI table
- Parse the GUIDed HOB (gCcEventEntryHobGuid) and create CC event log
- Measure handoff tables, Boot##### variables etc
- Measure Exit Boot Service failed
- Install CcMeasurement Protocol
Cc: Brijesh Singh <brijesh.singh@amd.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>
Cc: Ken Lu <ken.lu@intel.com>
Cc: Sami Mujawar <sami.mujawar@arm.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>
RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3853
Add PCDs to records LAML/LASA field in CC EVENTLOG ACPI table.
Cc: Brijesh Singh <brijesh.singh@amd.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>
Cc: Ken Lu <ken.lu@intel.com>
Cc: Sami Mujawar <sami.mujawar@arm.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>
RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3853
TdHobList and Configuration FV are external data provided by Host VMM.
These are not trusted in Td guest. So they should be validated , measured
and extended to Td RTMR registers. In the meantime 2 EFI_CC_EVENT_HOB are
created. These 2 GUIDed HOBs carry the hash value of TdHobList and
Configuration FV. In DXE phase EFI_CC_EVENT can be created based on these
2 GUIDed HOBs.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Brijesh Singh <brijesh.singh@amd.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>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3853
SecMeasurementLib is designed to do the measurement in SEC phase. In
current stage there are 2 functions introduced:
- MeasureHobList: Measure the Hoblist passed from the VMM.
- MeasureFvImage: Measure the FV image.
SecMeasurementLibTdx is the TDX version of the library.
Cc: Brijesh Singh <brijesh.singh@amd.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>
Cc: Ken Lu <ken.lu@intel.com>
Cc: Sami Mujawar <sami.mujawar@arm.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>
Since Cloud Hypervisor doesn't emulate an A20 gate register on I/O port
0x92, it's better to avoid accessing it when the platform is identified
as Cloud Hypervisor.
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
Acked-by: Jiewen Yao <jiewen.yao@intel.com>
Since Cloud Hypervisor doesn't support the fw_cfg mechanism, it's more
appropriate to rely on QemuFwCfgLibNull implementation of QemuFwCfgLib
since it provides a null implementation that will not issue any PIO
accesses to ports 0x510 and 0x511.
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
Acked-by: Jiewen Yao <jiewen.yao@intel.com>
There are few places in the codebase assuming QemuFwCfg will be present
and supported, which can cause some issues when trying to rely on the
QemuFwCfgLibNull implementation of QemuFwCfgLib.
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
Acked-by: Jiewen Yao <jiewen.yao@intel.com>
The FW_BASE_ADDRESS value provided by OvmfPkgDefines.fdf.inc is
incorrect for the CloudHv target. We know the generated firmware
contains a PVH ELF header, meaning it will be loaded according to the
address provided through this header. And since we know this address
isn't going to change as it's part of CloudHvElfHeader.fdf.inc, we can
hardcode it through a new include file CloudHvDefines.fdf.inc, which
replaces the generic one OvmfPkgDefines.fdf.inc.
With this change, we prevent the firmware from accessing MMIO addresses
from the address range 0xffc00000-0xffffffff since we know the firmware
hasn't been loaded on this address range.
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
Link in pcie and host bridge bits. Enables support for PCIe in microvm
(qemu-system-x86_64 -M microvm,pcie=on).
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3777
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
microvm places the 64bit mmio space at the end of the physical address
space. So mPhysMemAddressWidth must be correct, otherwise the pci host
bridge setup throws an error because it thinks the 64bit mmio window is
not addressable.
On microvm we can simply use standard cpuid to figure the address width
because the host-phys-bits option (-cpu ${name},host-phys-bits=on) is
forced to be enabled. Side note: For 'pc' and 'q35' this is not the
case for backward compatibility reasons.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
microvm doesn't support pflash and loads the firmware via -bios,
so we can't use the separate CODE and VARS files. Remove them.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
In current TDVF implementation all unaccepted memory passed in Hoblist
are tagged as EFI_RESOURCE_MEMORY_UNACCEPTED. They're all accepted before
they can be accessed. After accepting memory region, the Hob ResourceType
is unchanged (still be EFI_RESOURCE_MEMORY_UNACCEPTED).
TDVF Config-B skip PEI phase and it tries to find a memory region which
is the largest one below 4GB. Then this memory region will be used as the
firmware hoblist.
So we should walk thru the input hoblist and search for the memory region
with the type of EFI_RESOURCE_MEMORY_UNACCEPTED.
Because EFI_RESOURCE_MEMORY_UNACCEPTED has not been officially in PI spec.
So it cannot be defined in MdePkg/Include/Pi/PiHob.h. As a temporary
solution it is defined in Hob.c.
There is a patch-set for lazy-accept very soon. In that patch-set
EFI_RESOURCE_MEMORY_UNACCEPTED will be defined in MdeModulePkg.
Config-B: https://edk2.groups.io/g/devel/message/76367
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>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
According to GHCI Spec Table 2-1, in TDVMCALL R10 should be cleared
to 0 in input operands, and be checked for the return result.
https://cdrdv2.intel.com/v1/dl/getContent/726790
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>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
The SEV-ES bit of Fn800-001F[EAX] - Bit 3 is used for a host to
determine support for running SEV-ES guests. It should not be checked by
a guest to determine if it is running under SEV-ES. The guest should use
the SEV_STATUS MSR Bit 1 to determine if SEV-ES is enabled. This check
was not part of the original SEV-ES support and was added in
a91b700e38. Removing the check makes this code consistent with the
Linux kernel
Fixes: a91b700e38 ("Ovmf/ResetVector: Simplify and consolidate the SEV features checks")
Signed-off-by: Peter Gonda <pgonda@google.com>
Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
Min M Xu
Laszlo Ersek
Corvin Köhne
Pierre Gondois
Dimitrije Pavlov
Yuan Yu
Oliver Steffen
Anthony PERARD
Michael D Kinney
Kun Qin
Nicolas Ojeda Leon
Gerd Hoffmann
Sebastien Boeuf
Peter Gonda