| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4125
EPT-violation #VE should be always on shared memory, which means the
shared bit of the GuestPA should be set. But in current #VE Handler
it is not checked. When it occurs, stop TD immediately and log out
the error.
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>
Reviewed-by: Guorui Yu <ruogui.ygr@alibaba-inc.com>
Tested-by: Guorui Yu <ruogui.ygr@alibaba-inc.com>
|
|
RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3937
After EdkiiMemoryAcceptProtocol is implemented in TdxDxe driver, we can
call it to accept pages in DXE phase.
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>
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>
|
|
RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3937
Memory usage may exceed the amount accepted at the begining (SEC), TDVF
needs to accept memory dynamically when OUT_OF_RESOURCE occurs.
Another usage is in SetOrClearSharedBit. If a memory region is changed from
shared to private, it must be accepted again.
EdkiiMemoryAcceptProtocol is defined in MdePkg and is implementated /
installed in TdxDxe for Intel TDX memory acceptance.
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>
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>
|
|
RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3937
There are below major changes in PlatformInitLib/PlatformPei
1. ProcessHobList
The unaccepted memory is accepted if it is under 4G address.
Please be noted: in current stage, we only accept the memory under 4G.
We will re-visit here in the future when on-demand accept memory is
required.
2. TransferTdxHobList
Transfer the unaccepted memory hob to EFI_RESOURCE_SYSTEM_MEMORY hob
if it is accepted.
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>
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>
|
|
RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3937
BZ3937_EFI_RESOURCE_MEMORY_UNACCEPTED is defined in MdeModulePkg. The
files which use the definition are updated as well.
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>
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>
|
|
NOR flash emulation under KVM involves switching between two modes,
where array mode is backed by a read-only memslot, and programming mode
is fully emulated, i.e., the memory region is not backed by anything,
and the faulting accesses are forwarded to the VMM by the hypervisor,
which translates them into NOR flash programming commands.
Normally, we are limited to the use of device attributes when mapping
such regions, given that the programming mode has MMIO semantics.
However, when running under KVM, the chosen memory attributes only take
effect when in array mode, since no memory mapping exists otherwise.
This means we can tune the memory mapping so it behaves a bit more like
a ROM, by switching to EFI_MEMORY_WC attributes. This means we no longer
need a special CopyMem() implementation that avoids unaligned accesses
at all cost.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
|
|
Currently, when dealing with small updates that can be written out
directly (i.e., if they only involve clearing bits and not setting bits,
as the latter requires a block level erase), we iterate over the data
one word at a time, read the old value, compare it, write the new value,
and repeat, unless we encountered a value that we cannot write (0->1
transition), in which case we fall back to a block level operation.
This is inefficient for two reasons:
- reading and writing a word at a time involves switching between array
and programming mode for every word of data, which is
disproportionately costly when running under KVM;
- we end up writing some data twice, as we may not notice that a block
erase is needed until after some data has been written to flash.
So replace this sequence with a single read of up to twice the buffered
write maximum size, followed by one or two buffered writes if the data
can be written directly. Otherwise, fall back to the existing block
level sequence, but without writing out part of the data twice.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
|
|
NorFlashWriteSingleWord() switches into programming mode and back into
array mode for every single word that it writes. Under KVM, this
involves tearing down the read-only memslot, and setting it up again,
which is costly and unnecessary.
Instead, move the array mode switch into the callers, and only make the
switch when the writing is done.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
|
|
We never boot from NOR flash, and generally rely on the firmware volume
PI protocols to expose the contents. So drop the block I/O protocol
implementation from VirtNorFlashDxe.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
|
|
We only use NOR flash for firmware volumes, either for executable images
or for the variable store. So we have no need for exposing disk I/O on
top of the NOR flash partitions so let's remove it.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
|
|
We inherited a feature from the ArmPlatformPkg version of this driver
that never gets enabled. Let's remove it.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
|
|
QEMU's mach-virt is loosely based on ARM Versatile Express, and inherits
its NOR flash driver, which is now being used on other QEMU emulated
architectures as well.
In order to permit ourselves the freedom to optimize this driver for
use under KVM emulation, let's clone it into OvmfPkg, so we have a
version we can hack without the risk of regressing bare metal platforms.
The cloned version is mostly identical to the original, but it depends
on the newly added VirtNorFlashPlatformLib library class instead of the
original one from ArmPlatformPkg. Beyond that, only cosmetic changes
related to #include order etc were made.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
|
|
Create a new library class in Ovmf that duplicates the existing
NorFlashPlatformLib, but which will be tied to the VirtNorFlashDxe
driver that will be introduced in a subsequent patch. This allows us to
retire the original from ArmPlatformPkg.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
|
|
Per the UEFI specification, a device driver implementation should return
EFI_UNSUPPORTED if the ChildHandle argument in
EFI_COMPONENT_NAME2_PROTOCOL.GetControllerName() is not NULL.
Signed-off-by: Dimitrije Pavlov <Dimitrije.Pavlov@arm.com>
Reviewed-by: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Reviewed-by: Sunny Wang <sunny.wang@arm.com>
|
|
While the actual implementation (using qemu fw_cfg) is qemu-specific,
the idea to store the boot order as configured by the VMM in EFI
variables is not. So lets give the variables a more neutral name while
we still can (i.e. no stable tag yet with the new feature).
While being at it also fix the NNNN format (use %x instead of %d for
consistency with BootNNNN).
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
|
|
This reverts commit 60d55c4156523e5dfb316b7c0c445b96c8f8be81.
Now that we have stateless secure boot support (which doesn't
need SMM) in OVMF we can enable the build option for MicroVM.
Bring it back by reverting the commit removing it.
Also add the new PlatformPKProtectionLib.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Compiler flag is needed to make (stateless) secure boot be actually
secure, i.e. restore EFI variables from ROM on reset.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
|
|
In case the 64-bit pci mmio window is larger than the default size
of 32G be generous and hand out larger chunks of address space for
prefetchable mmio bridge windows.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
|
|
In case we have a reliable PhysMemAddressWidth use that to dynamically
size the 64bit address window. Allocate 1/8 of the physical address
space and place the window at the upper end of the address space.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Try detect physical address space, when successful use it.
Otherwise go continue using the current guesswork code path.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Add some qemu specific quirks to PlatformAddressWidthFromCpuid()
to figure whenever the PhysBits value returned by CPUID is
something real we can work with or not.
See the source code comment for details on the logic.
Also apply some limits to the address space we are going to use:
* Place a hard cap at 47 PhysBits (128 TB) to avoid using addresses
which require 5-level paging support.
* Cap at 40 PhysBits (1 TB) in case the CPU has no support for
gigabyte pages, to avoid excessive amounts of pages being
used for page tables.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
|
|
When finding an unsupported entry just skip over and continue
with the next entry instead of stop processing altogether.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
|
|
See comment for details. Needed to avoid the parser abort,
so we can continue parsing the bootorder fw_cfg file.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Traditional q35 memory layout is 2.75 GB of low memory, leaving room
for the pcie mmconfig at 0xb0000000 and the 32-bit pci mmio window at
0xc0000000. Because of that OVMF tags the memory range above
0xb0000000 as uncachable via mtrr.
A while ago qemu started to gigabyte-align memory by default (to make
huge pages more effective) and q35 uses only 2G of low memory in that
case. Which effectively makes the 32-bit pci mmio window start at
0x80000000.
This patch updates the mtrr setup code accordingly.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
|
|
PeilessStartupLib is running in SEC phase. In this phase global variable
is not allowed to be modified. This patch moves mPageTablePool to stack
and pass it as input parameter between functions.
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>
Signed-off-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
|
|
Wire up the newly added UefiDriverEntrypoint in a way that ties dispatch
of the Ip4Dxe and Ip6Dxe drivers to QEMU fw_cfg variables
'opt/org.tianocore/IPv4Support' and 'opt/org.tianocore/IPv6Support'
respectively.
Setting both variables to 'n' disables IP based networking entirely,
without the need for additional code changes at the NIC driver or
network boot protocol level.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
|
|
All QEMU based OVMF platforms override the same set of network
components, to specify NULL library class resolutions that modify the
behavior of those components in a QEMU specific way.
Before adding more occurrences of that, let's drop those definitions in
a common include file.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
|
|
Add a new library that can be incorporated into any driver built from
source, and which permits loading of the driver to be inhibited based on
the value of a QEMU fw_cfg boolean variable. This will be used in a
subsequent patch to allow dispatch of the IPv4 and IPv6 network protocol
driver to be controlled from the QEMU command line.
This approach is based on the notion that all UEFI and DXE drivers share
a single UefiDriverEntryPoint implementation, which we can easily swap
out at build time with one that will abort execution based on the value
of some QEMU fw_cfg variable.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
|
|
The DEBUG macro updated in this patch previously contained 11 print
specifiers in the debug string but passeed 13 arguments. This change
attempts to update the macro to the author's intention so the number
of specifiers match the number of arguments.
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: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
|
|
Both ACPI shutdown and ACPI PM timer devices has been moved to different
port addresses in the latest version of Cloud Hypervisor. These changes
need to be reflected on the OVMF firmware.
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
|
|
Add VgaInb() helper function to read vga registers. With that in place
fix the unblanking. We need to put the ATT_ADDRESS_REGISTER flip flop
into a known state, which is done by reading the
INPUT_STATUS_1_REGISTER. Reading the INPUT_STATUS_1_REGISTER only works
when the device is in color mode, so make sure that bit (0x01) is set in
MISC_OUTPUT_REGISTER.
Currently the mode setting works more by luck because
ATT_ADDRESS_REGISTER flip flop happens to be in the state we need.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
|
|
The function reads the boot order from qemu fw_cfg, translates it into
device paths and stores them in 'QemuBootOrderNNNN' variables. In case
there is no boot ordering configured the function will do nothing.
Use case: Allow applications loaded via 'qemu -kernel bootloader.efi'
obey the boot order.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
|
|
The current ACPI Reclaim memory size is set as 0x10 (64KiB). The ACPI
table size will be increased if the memory slots' number of the guest
gets increased. In the guest with more memory slots, the ACPI Reclaim
memory size may not be sufficient for hibernation. This may cause
resume failure of the hibernated guest that was booted up with a fresh
copied writable OVMF_VARS file. However, the failure doesn't happen in
following hibernation/resume cycles.
The ACPI_MAX_RAM_SLOTS is set as 256 in the current QEMU. With
ACPI_MAX_RAM_SLOTS, 18 pages are required to be allocated in ACPI
Reclaim memory. However, due to the 0x10 (16 pages) setting, 2 extra
pages will be allocated in other space. This may break the
hibernation/resume in the above scenario.
This patch increases the ACPI Reclaim memory size to 0x12, i.e.
PcdMemoryTypeEfiACPIReclaimMemory is set as 0x12 (18 pages).
Signed-off-by: Annie Li <annie.li@oracle.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Reference: https://bugzilla.tianocore.org/show_bug.cgi?id=4031
This patch is similar to the c477b2783f patch for Td guest.
Host VMM may inject OptionRom which is untrusted in Sev guest. So PCI
OptionRom needs to be ignored if it is Sev guest. According to
"Table 20. ACPI 2.0 & 3.0 QWORD Address Space Descriptor Usage"
PI spec 1.7, type-specific flags can be set to 0 when Address
Translation Offset == 6 to skip device option ROM.
Without this patch, Sev guest may shows invalid MMIO opcode error
as following:
Invalid MMIO opcode (F6)
ASSERT /home/abuild/rpmbuild/BUILD/edk2-edk2-stable202202/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c(1041): ((BOOLEAN)(0==1))
The OptionRom must be disabled both on Td and Sev guests, so we direct
use CcProbe().
Signed-off-by: "Lee, Chun-Yi" <jlee@suse.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
|
|
SECURE_BOOT_FEATURE_ENABLED is the build-flag defined when secure boot
is enabled. Currently this flag is used in below lib:
- OvmfPkg/PlatformPei
- PeilessStartupLib
So it is defined in below 5 .dsc
- OvmfPkg/CloudHv/CloudHvX64.dsc
- OvmfPkg/IntelTdx/IntelTdxX64.dsc
- OvmfPkg/OvmfPkgIa32.dsc
- OvmfPkg/OvmfPkgIa32X64.dsc
- OvmfPkg/OvmfPkgX64.dsc
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>
|
|
Set PcdEmuVariableNvStoreReserved with the value in PlatformInfoHob. It
is the address of the EmuVariableNvStore reserved in Pei-less startup.
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>
|
|
OvmfPkg/Library/NvVarsFileLib allows loading variables into emulated
varstore from a on-disk NvVars file. We can't allow that when secure
boot is active. So check secure-boot feature and shortcut the
ConnectNvVarsToFileSystem() function when sb is enabled.
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>
Suggested-by: 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>
|
|
EmuVariableNvStore is reserved and init with below 2 functions defined in
PlatformInitLib:
- PlatformReserveEmuVariableNvStore
- PlatformInitEmuVariableNvStore
PlatformInitEmuVariableNvStore works when secure boot feature is enabled.
This is because secure boot needs the EFI variables (PK/KEK/DB/DBX, etc)
and EmuVariableNvStore is cleared when OVMF is launched with -bios
parameter.
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>
|
|
ReserveEmuVariableNvStore is updated with below 2 functions defined in
PlatformInitLib:
- PlatformReserveEmuVariableNvStore
- PlatformInitEmuVariableNvStore
PlatformInitEmuVariableNvStore works when secure boot feature is enabled.
This is because secure boot needs the EFI variables (PK/KEK/DB/DBX, etc)
and EmuVariableNvStore is cleared when OVMF is launched with -bios
parameter.
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>
|
|
There are 3 functions added for EmuVariableNvStore:
- PlatformReserveEmuVariableNvStore
- PlatformInitEmuVariableNvStore
- PlatformValidateNvVarStore
PlatformReserveEmuVariableNvStore allocate storage for NV variables early
on so it will be at a consistent address.
PlatformInitEmuVariableNvStore copies the content in
PcdOvmfFlashNvStorageVariableBase to the storage allocated by
PlatformReserveEmuVariableNvStore. This is used in the case that OVMF is
launched with -bios parameter. Because in that situation UEFI variables
will be partially emulated, and non-volatile variables may lose their
contents after a reboot. This makes the secure boot feature not working.
PlatformValidateNvVarStore is renamed from TdxValidateCfv and it is used
to validate the integrity of FlashNvVarStore
(PcdOvmfFlashNvStorageVariableBase). It should be called before
PlatformInitEmuVariableNvStore is called to copy over the content.
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>
|
|
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 b261a30c900a8.
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
|
