Enable building the BaseRiscVFpuLib library for OvmfPkg to
* Enable the FPU and set it to state 'dirty'.
* Clear the fcsr CSR.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Let APs wait until the BSP has completed the register updates to remove
the CPU. This makes sure all APs stay in SMM mode until the CPU
hot-unplug operation is complete, which in turn makes sure the ACPI lock
is released only after the CPU hot-unplug operation is complete.
Some background: The CPU hotplug SMI is triggered from an ACPI function
which is protected by an ACPI lock. The ACPI function is in the ACPI
tables generated by qemu.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Currently TDVF gets cpu count information via fw_cfg, but
this information can also be retrieved by calling of TdCall.TdInfo.
And TdCall is responded by tdx-module which is trust.
So, from the security perspective we shall use TdCall.Tdinfo instead
of fw_cfg.
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>
RiscVVirt.dsc.inc includes NetworkPkg/NetworkLibs.dsc.inc. However
RiscVVirt.dsc.inc is only ever included by RiscVVirtQemu.dsc, which
has already included NetworkPkg/Network.dsc.inc, a general include
file which brings in all the required includes for Network features
at once, including NetworkPkg/NetworkLibs.dsc.inc.
Signed-off-by: Mike Beaton <mjsbeaton@gmail.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=48297f17a15 (2024/02/22)
"OvmfPkg: Shell*.inc: allow building without network support"
breaks building OVMF with `-D NETWORK_ENABLE=0`.
Before this commit we could build OVMF e.g. with the following
command in the OvmfPkg directory:
./build.sh -D NETWORK_ENABLE=0
After the commit the same command fails early with:
/home/user/OpenSource/edk2/OvmfPkg/OvmfPkgX64.dsc(15):
error F001: Pcd (gEfiNetworkPkgTokenSpaceGuid.PcdAllowHttpConnections)
defined in DSC is not declared in DEC files referenced in INF files in
FDF. Arch: ['X64']
The problem applies in Intel OvmfPkg platforms.
Additionally, it applies in various other OvmfPkg
platforms, but is masked buy another issue; namely
that these platforms incorrectly still include some
network packages when most are disabled.
(A fix for that issue has previously been
made, in OvmfPkg Intel platforms only, by
d933ec1 followed by
7f17a15 .)
This commit conditionally removes the undefined Pcd references
in all OvmfPkg platforms which are now affected by this
issue, and in all those which would be affected as and
when the other issue mentioned above is fixed.
Signed-off-by: Mike Beaton <mjsbeaton@gmail.com>
After the loongarch flash block size is changed from 128K to 256K,
qemu requires that the UEFI firmware size be aligned with the flash block size(256K).
Otherwise, the firmware cannot be loaded,
Use the following code to resolve the old firmware loading problem:
mv QEMU_EFI.fd QEMU_EFI.fd-bak
cat QEMU_EFI.fd-bak /dev/zero | head -c 16m > ./QEMU_EFI.fd
mv QEMU_VARS.fd QEMU_VARS.fd-bak
cat QEMU_VARS.fd-bak /dev/zero | head -c 16m > ./QEMU_VARS.fd
For the new firmware, we refer to other architecture UEFI and
set the UEFI firmware size to align with the flash block size(256K).
So for this patch, we set the UEFI firmware size to 256K alignment.
Cc: Bibo Mao <maobibo@loongson.cn>
Cc: Chao Li <lichao@loongson.cn>
Signed-off-by: Xianglai Li <lixianglai@loongson.cn>
Refer to the section 2.1 of tdx-virtual-firmware-design-guide spec,
APCI S3 is not supported in TDVF.
Therefore, TDVF should not read the S3 status via fw_cfg and always
set it as unsupported.
spec: https://cdrdv2.intel.com/v1/dl/getContent/733585
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 the PEI Hob service is ready after PEIM loaded,
TDVF should build the Hob for TdHob and Cfv event
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: Ceping Sun <cepingx.sun@intel.com>
Currently, TDVF gets LowMemory and FistNonAddress from the e820tables
via fw_cfg, while TD-Hob can also provide the memory info of LowMemory
and FistNonAddress.
In current stage e820tables are not measured but TD-Hob is measured in
early phase by TDVF.
So, from the security perspective we'd better use the information from
TD-Hob instead of e820tables.
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>
When launching a SEV-SNP VM, the ROM is not all that must be measured.
The OvmfSevMetadata sections describe ranges of memory that must be
measured with different types than PAGE_TYPE_NORMAL, except one. The
SevSnpKernelHashes page is also PAGE_TYPE_NORMAL, but is populated by
the VMM from configuration data that is separate from the OVMF build
itself. To more compactly provide reference values for the measurement
of the firmware separately from the kernel hashes, it's advantageous to
measure as much known information as possible first.
Whereas VMMs are permitted to measure these sections in any order they
prefer, the normative order of how they appear in the .fd is easiest to
follow. This change is semantics-preserving. Measurement calculation
tools that do not follow the normative ordering would need updating to
accommodate, but I don't know of any. The accounting for EC2 moving the
CPUID page to the end of measurement would be unchanged.
This change is to improve performance of a proposed launch update event
log to separate responsibility for initially measured data before VM
launch, application/vnd.amd.sevsnp.launch-updates+cbor:
https://github.com/deeglaze/draft-deeglaze-amd-sev-snp-corim-profile
Signed-off-by: Dionna Glaze <dionnaglaze@google.com>
There are a number of mostly older guests such as RHEL-7 which do not
support 5-level paging. This patch adds support for switching from
5-level paging mode back to 4-level paging mode. This is done in PEI,
after inspecting the address space needed (installed memory and
reservations configured via fw_cfg).
By default small guests (which need less than 1 TB) will use 4-level
paging mode. There is a fw_cfg override though, so it is possible to
force the one or the other this way:
qemu-system-x86_64 -fw_cfg name=opt/org.tianocode/PagingLevel,string=5
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Since the LoongArch SPEC has adjusted the CSR 0x20 register name and
the MdePkg also added the new name, so enable it in OvmfPkg.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Chao Li <lichao@loongson.cn>
When booting OvmfXen, the ACPI interface for shutdown/reset might not
be available, instead use the hypercall interface.
While it's probably possible to use the hypercall in all cases, we
keep using the same interface while it still possible. That is ACPI on
HVM guest, and fallback to hypercall on PVH guest.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
Add a new function to allow to make an hypercall to shutdown the
machine.
This import "sched.h" public header from Xen Project's repo. Some
changes have been made to be closer to EDK2's coding style.
Add the entire OvmfPkg/Include/IndustryStandard/Xen/ directory to
LicenseCheck ignore. All the existing header files, as well as the new
sched.h, are MIT licensed.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
XenHypercallLib now makes direct hypercalls, so HyperPages is
unnecessary and can be removed.
Change the XenPvhDetected() ASSERT to use the Xen version. That has
never been 0, AFAIK.
Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
This removes the need to allocate memory for the hypercall page,
particularly for use during runtime. This also makes the library usable
in all phases, so LIBRARY_CLASS can remove the restrictions.
The processor vendor is used to select vmmcall or vmcall instructions.
The listed vendors are those in the Xen tree.
Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
In the current code, TDVF reads the PcdSetNxForStack value via fw_cfg ,
but overwrites it with a fixed value after the read is complete.
In this patch, TDVF removes the redundant logic code.
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>
In the system boot phase, if OS postpone onlining some CPU
until later, the sec page tables could be overwritten.
So, TDVF needs to reserve the initial page tables that would be
used by APs on Mailbox wakeup.
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>
Cc: Kirill A Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Ceping Sun <cepingx.sun@intel.com>
Since the PGD series registers are in an unknown state when reset, some
simulators will hang when restarting if these registers are not cleared,
so they are cleared in this patch.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Chao Li <lichao@loongson.cn>
According to the TCG EFI platform specification, the firmware must
measure the EV_SEPARATOR event into PCRs 0-7. As PCR[1] and PCR[7]
map to RTMR[0], and PCRs [2-6] map to RTMR[1], it is necessary to
measure one EV_SEPARATOR event into RTMR[0] and another one into
RTMR[1].
An issue is found in TdTcg2Dxe that 2 EV_SEPARATOR events are measured
to RTMR[0] but no EV_SEPARATOR event is measured to RTMR[1]. This
patch fixes the above issue.
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Qinkun Bao <qinkun@google.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Michael Roth <michael.roth@amd.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
The patch at "1fc55a3933b0 OvmfPkg: Use heap memory
for virtio-scsi request" modified the virtio-scsi
request header memory to be allocated from the heap.
In doing so the request structure header which was
a local variable on the stack was converted to be a
pointer. This required adjusting the size computation
for the request header to reflect that the structure
was changed to a pointer.
Unfortunately, this was missed out in the call to
VirtioAppendDesc() for enqueuing the request due to
which only 8 bytes were being shared with the host
instead of the size of the VIRTIO_SCSI_REQ structure
which is 51 bytes.
This resulted in the following error message to
be printed by qemu: "qemu-system-<arch>: wrong size
for virtio-scsi headers" and the virtio-scsi
functionality degraded.
Therefore, pass the correct size of the virtio-scsi
request header when enqueuing the request.
Reported-by: Aithal Srikanth <sraithal@amd.com>
Tested-by: Aithal Srikanth <sraithal@amd.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
The storage space for virtio-scsi request header being shared
with the host was from the stack as the request structure was
a local function variable.
A bug in the VMM can corrupt the stack space, and such issues
can be very hard to debug.
Note: This is only an issue with a normal guest VM (non-CCA).
A CCA guest VM would perform bounce buffering for sharing the
data and therefore not have this issue.
Instead of using the stack for sharing the data with the host,
memory can be allocated from the heap pool. However, pool
allocations are not any safer in terms of pages being shared
between different allocations, and so mapping a pool allocation
for DMA may expose it to potential corruption by the VMM in
exactly the same way. The only difference is the potential
impact on program behaviour, which is much higher with the
stack.
Additionally, for guest-side corruption heap allocations can
take advantage by turning on heap guard to help find the bug.
Therefore, minor improvement can be achieved by allocating
memory for the virtio-scsi request header from the heap for
sharing with the host.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
The storage space for virtio-blk request header being shared
with the host was from the stack as the request structure was
a local function variable.
A bug in the VMM can corrupt the stack space, and such issues
can be very hard to debug.
Note: This is only an issue with a normal guest VM (non-CCA).
A CCA guest VM would perform bounce buffering for sharing the
data and therefore not have this issue.
Instead of using the stack for sharing the data with the host,
memory can be allocated from the heap pool. However, pool
allocations are not any safer in terms of pages being shared
between different allocations, and so mapping a pool allocation
for DMA may expose it to potential corruption by the VMM in
exactly the same way. The only difference is the potential
impact on program behaviour, which is much higher with the
stack.
Additionally, for guest-side corruption heap allocations can
take advantage by turning on heap guard to help find the bug.
Therefore, minor improvement can be achieved by allocating
memory for the virtio-blk request header from the heap for
sharing with the host.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
These libraries do not implement EfiResetSystemLib to begin with, and
this library class is going to be dropped. So drop these bogus
references first.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Open the network option to enable networking on the LoongArch QEMU
platform.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Chao Li <lichao@loongson.cn>
Keep ZKR feature disabled by default until HW supports
it. Feature is implemented in RISC-V BaseRngLib.
Cc: Andrei Warkentin <andrei.warkentin@intel.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Sunil V L <sunilvl@ventanamicro.com>
Signed-off-by: Dhaval Sharma <dhaval@rivosinc.com>
Co-authored-by: Tim Wawrzynczak <tim@rivosinc.com>
There was a wild pointer in Fdt16550SerialProtHookLib which pointed to
an unknown space, which was very wrong and has been fixed.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Chao Li <lichao@loongson.cn>
CC_MEASUREMENT_ENABLE is designed to control the loading of TdTcg2Dxe
driver which is for EFI_CC_MEASUREMENT_PROTOCOL. TdTcg2Dxe is TD-Guest
specific driver.
From the security perspective a TD-Guest shall always load the TdTcg2Dxe
driver so that EFI_CC_MEASUREMENT_PROTOCOL is installed and booting
events are measured and extended to RTMRs.
TdTcg2Dxe will check if it is running in a TD-Guest. If not then it
returns right now and no EFI_CC_MEASUREMENT_PROTOCOL is installed.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Michael Roth <michael.roth@amd.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
With the commit ce4c76e (“OvmfPkg/Sec: Setup MTRR early
in the boot process.”), we find an unexpected #VE is triggered
in TD-Guest.
The background of importing the above commit is that:
Before running lzma uncompress of the main firmware volume,
if not correctly set MTRR, that would make the uncompress be
extremely slow.
Detailed discussion info can refer to below links:
https://edk2.groups.io/g/devel/message/114202https://edk2.groups.io/g/devel/message/114977
Refer to [intel-tdx-module-1.5-base-spec] Section 11.3 and
section11.6.1, CR0.CD is enforced to 0 in TD-Guest.
And refer to section 18.2.1.4, TDX module MTRR emulation
enforces WB in VMM.
Currently the initial MTRR are:
- Td-Guest : MTRR disabled, Type is WB.
- Non-Td-Guest : MTRR disabled, Type is UC.
In DXE phase, OVMF/TDVF would check the MTRR Type for MMIO
(in CpuSetMemoryAttributes -> MtrrGetMemoryAttribute ->
MtrrGetMemoryAttributeworker:
https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/Library/MtrrLib/MtrrLib.c#L929
).
If MTRR is disabled, it always returns UC. Otherwise, it returns
the actual value.
If it checks that the type is not UC then the MTRR is programmed.
It is required to disable cache by setting CR0.CD to 1. That will trigger
an unexpected #VE in TD-Guest.
Based on above analysis we propose to skip "Setup MTRR early" in
TD-Guest because of:
- TD-Guest doesn’t have the issue that lzma uncompress extremely slow.
- This patch will trigger an unexpected #VE in TD-Guest.
intel-tdx-module-1.5-base-spec:
https://cdrdv2.intel.com/v1/dl/getContent/733575
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>
Because the complex dependency between SerialPortLib and
PciExpressLib leads to multiple references to the lib
library in the loongarch dsc file, optimizing SerialPortLib
now simplifies multiple references to lib in the dsc file.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Bibo Mao <maobibo@loongson.cn>
Cc: Chao Li <lichao@loongson.cn>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Xianglai Li <lixianglai@loongson.cn>
Signed-off-by: Xianglai Li <lixianglai@loongson.cn>
Write the feature bit into PcdConfidentialComputingGuestAttr
and enable DebugVirtualization in PEI, SEC, DXE.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Michael Roth <michael.roth@amd.com>
Cc: Min Xu <min.m.xu@intel.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Alexey Kardashevskiy <aik@amd.com>
---
Changes:
v5:
* "rb" from Tom
v4:
* s/DebugSwap/DebugVirtualization/g
The SEV-ES DebugVirtualization feature enables type B swapping of
debug registers on #VMEXIT and makes #DB and DR7 intercepts
unnecessary and unwanted.
When DebugVirtualization is enabled, this stops booting if
interaction from the HV.
Add new API to PEI, SEC, DXE.
This does not change the existing behaviour yet.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Michael Roth <michael.roth@amd.com>
Cc: Min Xu <min.m.xu@intel.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Alexey Kardashevskiy <aik@amd.com>
---
Changes:
v5:
* "rb" from Tom
v4:
* s/DebugSwap/DebugVirtualization/
If kernel hashes are enabled but no initrd is provided,
QEMU will still create an entry in the hash table, but it
will be the hash of an empty buffer.
Remove the explicit check for the length of the blob.
This logic will be handled by the later hash comparison,
which will still fail when the blob is not present
but is expected, but will pass when the blob is not present
and the hash table contains a hash of an empty buffer.
Signed-off-by: Tobin Feldman-Fitzthum <tobin@linux.ibm.com>
Signed firmware measurements are allowed to be passed along to in the
TCG and CC event logs according to the TCG PC Client Platform Firware
Profile. The event logs include events that Tcg2Dxe reads from
appropriately GUIDed HOBs, so allow opt/org.tianocode/sp800155evt/%d to
pass along events that the VMM sees fit to provide. One event per
number, starting from 0, increasing by 1 until there are no more
contiguous files.
The VMM may provide reference measurements through UEFI variables that
it references from the SP800-155 event3 structure given the appropriate
RIM locator type, or via URL, etc.
Each event read from fw_cfg, is written one-by-one to
a EFI_HOB_GUID_TYPE HOB created for the event. The name they target
gTcg800155PlatformIdEventHobGuid for the later Dxe driver to use to
extend the event log.
Signed-off-by: Dionna Glaze <dionnaglaze@google.com>
Specifically before running lzma uncompress of the main firmware volume.
This is needed to make sure caching is enabled, otherwise the uncompress
can be extremely slow.
Adapt the ASSERTs and MTRR setup in PlatformInitLib to the changes.
Background: Depending on virtual machine configuration kvm may uses EPT
memory types to apply guest MTRR settings. In case MTRRs are disabled
kvm will use the uncachable memory type for all mappings. The
vmx_get_mt_mask() function in the linux kernel handles this and can be
found here:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/x86/kvm/vmx/vmx.c?h=v6.7.1#n7580
In most VM configurations kvm uses MTRR_TYPE_WRBACK unconditionally. In
case the VM has a mdev device assigned that is not the case though.
Before commit e8aa4c6546 ("UefiCpuPkg/ResetVector: Cache Disable
should not be set by default in CR0") kvm also ended up using
MTRR_TYPE_WRBACK due to KVM_X86_QUIRK_CD_NW_CLEARED. After that commit
kvm evaluates guest mtrr settings, which why setting up MTRRs early is
important now.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
A malicious host may be able to undermine the fw_cfg
interface such that loading a blob fails.
In this case rather than continuing to the next boot
option, the blob verifier should halt.
For non-confidential guests, the error should be non-fatal.
Signed-off-by: Tobin Feldman-Fitzthum <tobin@linux.ibm.com>
The Blob Verifier checks boot artifacts against a hash table
injected by the hypervisor and measured by hardware.
Update the Blob Verifier to enter a dead loop if the artifacts
do not match.
The verifier still returns ACCESS_DENIED in some cases, but this
is considered non-fatal. These non-fatal cases occur when the
artifact cannot be verified because the hashes table makes no
claims about the artifiact (e.g. if the hashes table is not present
or if there is no entry for the blob in question).
Since the hash table is reflected in the launch measurement,
it is okay to continue the boot in these cases.
If the hash table does contain expected hash values, the boot cannot
continue if the provided blobs do not match.
In these cases we enter a dead loop to make sure no guest can boot
with a TCB that does not reflect the launch measurement.
Signed-off-by: Tobin Feldman-Fitzthum <tobin@linux.ibm.com>
Some platforms (such as SBSA-QEMU on recent builds of the emulator) only
tolerate misaligned accesses to normal memory, and raise alignment
faults on such accesses to device memory, which is the default for PCIe
MMIO BARs.
When emulating a PCIe graphics controller, the framebuffer is typically
exposed via a MMIO BAR, while the disposition of the region is closer to
memory (no side effects on reads or writes, except for the changing
picture on the screen; direct random access to any pixel in the image).
In order to permit the use of such controllers on platforms that only
tolerate these types of accesses for normal memory, it is necessary to
remap the memory. Use the DXE services to set the desired capabilities
and attributes.
Hide this behavior under a feature PCD so only platforms that really
need it can enable it. (OVMF on x86 has no need for this)
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Bhyve has added support for the bootorder FwCfg file some time ago
[1][2]. This FwCfg file is currently ignored by the OVMF and has no
effect. Copy the relevant code from Qemu to Bhyve to make it usable.
[1] 6632a0a4e3
[2] 480bef9481
Signed-off-by: Corvin Köhne <c.koehne@beckhoff.com>
Add support for building LoongArchVirtQemu platform in CI
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4584
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Chao Li <lichao@loongson.cn>
This library provides interface related to restart and shudown the
LoongArch64 virtual machine.
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4584
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: Bibo Mao <maobibo@loongson.cn>
Cc: Dongyan Qian <qiandongyan@loongson.cn>
Signed-off-by: Chao Li <lichao@loongson.cn>
Co-authored-by: Xianglai Li <lixianglai@loongson.cn>
Co-authored-by: Bibo Mao <maobibo@loongson.cn>
This library is provides real time clock for LoongArch virtual machine.
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4584
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: Bibo Mao <maobibo@loongson.cn>
Cc: Dongyan Qian <qiandongyan@loongson.cn>
Signed-off-by: Chao Li <lichao@loongson.cn>
Co-authored-by: Baoqi Zhang <zhangbaoqi@loongson.cn>
Co-authored-by: Xianglai Li <lixianglai@loongson.cn>
Added a new GUID use for store the RTC register base address if the
platform can not uses the dynamic PCD in PEI stage.
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4584
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Chao Li <lichao@loongson.cn>
Add a early serial port output library into LoongArchVirt that named
EarlyFdtSerialPortLib16550, this library is referenced from
MdeModulePkg.
This library is used in the PEI phase. Since the serial port address can
not be saved in memory of the LoongArch QEMU virtual machine in the PEI
phase, the serial prot base address will be obtained from the FDT before
each output.
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4584
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: Bibo Mao <maobibo@loongson.cn>
Cc: Dongyan Qian <qiandongyan@loongson.cn>
Signed-off-by: Chao Li <lichao@loongson.cn>
Co-authored-by: Xianglai Li <lixianglai@loongson.cn>
Add a serial port hook library in LoongArchVirt named
Fdt16550SerialProtHookLib, this library is referenced from ArmVirtPkg.
LoongArch QEMU virtual machine uses register of LOONGARCH_CSR_KS1 to
transfer serial port base addres from the PEI phase to the DXE phase.
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4584
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: Bibo Mao <maobibo@loongson.cn>
Cc: Dongyan Qian <qiandongyan@loongson.cn>
Signed-off-by: Chao Li <lichao@loongson.cn>
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Added a new library for LoongArch, it use for initialization the CPU
MMU, it consumed the CpuMmuLib.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Chao Li <lichao@loongson.cn>
Co-authored-by: Baoqi Zhang <zhangbaoqi@loongson.cn>
Co-authored-by: Dongyan Qian <qiandongyan@loongson.cn>
Co-authored-by: Xianglai Li <lixianglai@loongson.cn>
Co-authored-by: Bibo Mao <maobibo@loongson.cn>
Since commit 4c4ceb2ceb ("NetworkPkg: SECURITY PATCH CVE-2023-45237"),
networking modules depend on gEfiRngProtocolGuid but nothing in OvmfXen
provides it. This is visible in the logs as several modules present but
not loading:
Driver A2F436EA-A127-4EF8-957C-8048606FF670 was discovered but not loaded!!
Driver E4F61863-FE2C-4B56-A8F4-08519BC439DF was discovered but not loaded!!
Driver 025BBFC7-E6A9-4B8B-82AD-6815A1AEAF4A was discovered but not loaded!!
Driver 529D3F93-E8E9-4E73-B1E1-BDF6A9D50113 was discovered but not loaded!!
Driver 94734718-0BBC-47FB-96A5-EE7A5AE6A2AD was discovered but not loaded!!
Include SecurityPkg/RandomNumberGenerator/RngDxe to fix this.
Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
PcdCpuSmmApSyncTimeout2 PCD was added in previous patch
(52d0a208), this patch is to override PcdCpuSmmApSyncTimeout2
to 10ms (same as PcdCpuSmmApSyncTimeout) so as to align with
original behavior.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
Add OvmfRng include snippets with the random number generator
configuration for OVMF. Include RngDxe, build with BaseRngLib,
so the rdrand instruction is used (if available).
Also move VirtioRng to the include snippets.
Use the new include snippets for OVMF builds.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
The guest os which depends on vbeshim for video support is -- according
to the comments -- Windows 2008 R2. Which went EOL in January 2020,
more than four years ago.
Time to retire VbeShim. RIP.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Add support for GuestPhysBits (cpuid 0x80000008, eax, bits 23:16).
GuestPhysBits is a field which can be set by the hypervisor to inform
the guest about the /usable/ physical address space bits. This can be
smaller than the PhysBits of the CPU, for example because of nested
paging limitations.
OVMF will read GuestPhysBits, log the value, in case it is set use it
as upper limit.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Add dsc + fdf include files to add the MorLock drivers to the build.
Add the include files to OVMF build configurations.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This library is copied from ArmVirtPkg, in the Arm version, the value of
PcdFlashNvStorageVariableBase, PcdFlashNvStorageFtwWorkingBase and
PcdFlashNvStorageFtwSpareBase are hardcoded in INC file.
This version will calculate them from FDT resource and using the set PCD
to store when the NorFlashInitialise is called. By default, the first
available flash(not used for storage UEFI code) as NV variable storage
medium.
In this way, UEFI can better handle the change of flash base address,
which is suitable for different cpu architecture board implementation.
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4770
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Chao Li <lichao@loongson.cn>
Co-authored-by: Xianglai Li <lixianglai@loongson.cn>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Save MTRR by lockbox in CpuS3DataDxe. In S3 boot,
The MTRR setting will be restored in S3Resume.c
in following patches. Then S3Resume.c will wakeup
all APs to load the MTRR setting. This can avoid
waking up APs in CpuS3.c.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Reviewed-by: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Jiaxin Wu <jiaxin.wu@intel.com>
Add a 'Ready' boolean to the driver state struct, use it to track
whenever the device is ready to be used. In case it is not ready
throw an EFI_DEVICE_ERROR instead of sending a request which will
never receive an answer.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Encrypted and Special Purpose resource attributes are introduced in
PI 1.8 Specification. This patch is to update VMM Hob list integrity
check to recognize these resource attributes.
Signed-off-by: Du Lin <du.lin@intel.com>
This patch adds Hash2DxeCrypto to OvmfPkg. The Hash2DxeCrypto is
used to provide the hashing protocol services.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Doug Flick [MSFT] <doug.edk2@gmail.com>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
EFI_RESOURCE_MEMORY_UNACCEPTED has been officially defined in the PI
1.8 specification. So all temporary solutions have been replaced with
the actual definition.
Cc: Felix Polyudov <felixp@ami.com>
Cc: Dhanaraj V <vdhanaraj@ami.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Sachin Ganesh <sachinganesh@ami.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Based on gSmmBaseHobGuid:
If gSmmBaseHobGuid found, means SmBase info has been relocated
and recorded in the SmBase array.
So, this patch check smbase relocation is done or not in
SmmCpuFeaturesInitializeProcessor().
With SmmRelocationLib, gSmmBaseHobGuid will be always created.
Here this patch just makes the function/logic correct. The SMM
Relocation logic can be totally cleaned from the
SmmCpuFeaturesLib. But it will happen in the future patch set,
this patch does not target to the cleanup work.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
This patch refines the SmmAccess implementation:
1. SmramMap will be retrieved from the
gEfiSmmSmramMemoryGuid instead of original from
the TSEG Memory Base register.
2. Remove the gEfiAcpiVariableGuid creation, thus
the DESCRIPTOR_INDEX definition can be also cleaned.
3. The gEfiAcpiVariableGuid HOB is moved to the
OvmfPkg/Library/PlatformInitLib/PlatformInitLib.inf.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
In the PiSmmCpuDxeSmm driver, SMRAM allocation for SMI
handlers and processor Save State areas was traditionally
performed using the Smst->AllocatePages() function during
the DXE phase. The introduction of SmmRelocationLib
changes this process by moving the allocation to the PEI
phase, where Smst->AllocatePages() is not accessible.
Instead, the allocation is now handled by partitioning
the SMRAM based on the information provided by a GUID HOB
(identified by gEfiSmmSMramMemoryGuid).
This patch is to ensure that OVMF produces the
gEfiSmmSMramMemoryGuid HOB, allowing SmmRelocationLib to
reserve the necessary memory for SMBASE relocation.
More info for the change:
1. The EFI_SMM_SMRAM_MEMORY_GUID HOB, as defined in the PI
specification, vol.3, section 5, which is used to describe
the SMRAM memory regions supported by the platform. This HOB
should be produced during the memory detection phase to
align with the PI spec.
2. In addition to the memory reserved for ACPI S3 resume,
an increasing number of features require reserving SMRAM
for specific purposes, such as SmmRelocation. Other
advanced features in Intel platforms also necessitate
this. The implementation of these features varies and is
entirely dependent on the platform. This is why an
increasing number of platforms are adopting the
EFI_SMM_SMRAM_MEMORY_GUID HOB for SMRAM description.
3. It is crucial that the SMRAM information remains
consistent when retrieved from the platform, whether
through the SMM ACCESS PPI/Protocol or the
EFI_SMM_SMRAM_MEMORY_GUID HOB. Inconsistencies can lead
to unexpected issues, most commonly memory region conflicts.
4. The SMM ACCESS PPI/Protocol can be naturally
implemented for general use. The common approach is to
utilize the EFI_SMM_SMRAM_MEMORY_GUID HOB. For reference,
see the existing implementation in the EDK2 repository at
edk2/UefiPayloadPkg/SmmAccessDxe/SmmAccessDxe.inf and
edk2-platforms/Silicon/Intel/IntelSiliconPkg/Feature/
SmmAccess/Library/PeiSmmAccessLib/PeiSmmAccessLib.inf.
Next patch will refine the OVMF SMM Access to consume
the EFI_SMM_SMRAM_MEMORY_GUID HOB.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
There are below 2 differences between AMD & OVMF according
existing implementation:
1.The mode of the CPU check is different between the AMD & OVMF.
OVMF:
CpuSaveState->x86.SMMRevId & 0Xffff
AMD:
LMAValue = (UINT32)AsmReadMsr64 (EFER_ADDRESS) & LMA
2.Existing SmBase configuration is different between the
AMD & OVMF.
OVMF:
if ((CpuSaveState->x86.SMMRevId & 0xFFFF) == 0) {
CpuSaveState->x86.SMBASE = mSmBaseForAllCpus[CpuIndex];
} else {
CpuSaveState->x64.SMBASE = mSmBaseForAllCpus[CpuIndex];
}
AMD:
AmdCpuState->x64.SMBASE = mSmBaseForAllCpus[CpuIndex];
This patch provides the SmmRelocationLib library instance
for OVMF to handle the logic difference, and it won't change
the existing implementation code logic.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zeng Star <star.zeng@intel.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
The current #VC handler guards against MMIO to addresses that are mapped
with the encryption bit set, but has an special exception for MMIO
accesses to the APIC base address so allow for early access during SEC.
Now that the SEC page table has the encryption bit cleared for the APIC
base address range, there is no longer any need for this special
handling. Go ahead and remove it.
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Erdem Aktas <erdemaktas@google.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 Roth <michael.roth@amd.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
For the most part, OVMF will clear the encryption bit for MMIO regions,
but there is currently one known exception during SEC when the APIC
base address is accessed via MMIO with the encryption bit set for
SEV-ES/SEV-SNP guests. In the case of SEV-SNP, this requires special
handling on the hypervisor side which may not be available in the
future[1], so make the necessary changes in the SEC-configured page
table to clear the encryption bit for 4K region containing the APIC
base address.
[1] https://lore.kernel.org/lkml/20240208002420.34mvemnzrwwsaesw@amd.com/#t
Suggested-by: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Jianyong Wu <jianyong.wu@arm.com>
Cc: Anatol Belski <anbelski@linux.microsoft.com>
Signed-off-by: Michael Roth <michael.roth@amd.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Future changes will make use of CpuPageTableLib to handle splitting
page table mappings during SEC phase. While it's not strictly required
by hardware, CpuPageTableLib relies on non-leaf PTEs never having the
encryption bit set, so go ahead change the page table setup code to
satisfy this expectation.
Suggested-by: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Erdem Aktas <erdemaktas@google.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 Roth <michael.roth@amd.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
All of platforms are switching to QemuFwCfgMmioDxeLib.inf, remove
QemuFwCfgLibMmio.inf now.
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4755
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Chao Li <lichao@loongson.cn>
Enable QemuFwCfgMmioDxeLib.inf in RiscVVirtQemu.dsc
Build-tested only (with "RiscVVirtQemu.dsc").
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4755
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Sunil V L <sunilvl@ventanamicro.com>
Cc: Andrei Warkentin <andrei.warkentin@intel.com>
Signed-off-by: Chao Li <lichao@loongson.cn>
Copy QemuFwCfgLibMmio.inf to QemuFwCfgMmioDxeLib.inf,
QemuFwCfgLibMmio.inf will be deleted when all platforms switching is
completed.
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4755
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Chao Li <lichao@loongson.cn>
Added the PEI stage library for QemuFwCfgMmioLib, which uses the FDT to
find the fw_cfg and parse it.
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4755
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Co-authored-by: Xianglai Li <lixianglai@loongson.cn>
Signed-off-by: Chao Li <lichao@loongson.cn>
Added the HOB methods to load and store the QEMU firmware configure
address, data address and DMA address, which are not enabled during the
DXE stage.
Build-tested only (with "ArmVirtQemu.dsc and RiscVVirtQemu.dsc").
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4755
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Sunil V L <sunilvl@ventanamicro.com>
Cc: Andrei Warkentin <andrei.warkentin@intel.com>
Signed-off-by: Chao Li <lichao@loongson.cn>
Separate QemuFwCfgLibMmio.c into two files named QemuFwCfgLibMmio.c and
QemuFwCfgLibMmioDxe.c, added a new header named
QemuFwCfgLibMmioInternal.h for MMIO version.
Some DXE stage variables became non-static in this patch, they will be
restored to static in the next patch.
Build-tested only (with "ArmVirtQemu.dsc and RiscVVirtQemu.dsc").
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4755
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Sunil V L <sunilvl@ventanamicro.com>
Cc: Andrei Warkentin <andrei.warkentin@intel.com>
Signed-off-by: Chao Li <lichao@loongson.cn>
Added a new GUID for QemuFwCfgLib MMIO version, called
gQemuFirmwareResourceHobGuid, which is used to save QEMU firmware
configure resource during PEI stage.
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4755
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Chao Li <lichao@loongson.cn>
The VirtHstiDxe does not work in confidential guests. There also isn't
anything we can reasonably test, neither flash storage nor SMM mode will
be used in that case. So just skip driver load when running in a
confidential guest.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Fixes: 506740982b ("OvmfPkg/VirtHstiDxe: add code flash check")
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Tested-by: Srikanth Aithal <sraithal@amd.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Ensure that when a #VC exception happens, the instruction at the
instruction pointer matches the instruction that is expected given the
error code. This is to mitigate the ahoi WeSee attack [1] that could
allow hypervisors to breach integrity and confidentiality of the
firmware by maliciously injecting interrupts. This change is a
translated version of a linux patch e3ef461af35a ("x86/sev: Harden #VC
instruction emulation somewhat")
[1] https://ahoi-attacks.github.io/wesee/
Cc: Borislav Petkov (AMD) <bp@alien8.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Adam Dunlap <acdunlap@google.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Detects qemu config issue: code pflash is writable.
Checked for both PC and Q35.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Konstantin Kostiuk <kkostiuk@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Detects qemu config issue: vars pflash is not in secure mode (write
access restricted to smm). Applies to Q35 with SMM only.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Konstantin Kostiuk <kkostiuk@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
The driver supports qemu machine types 'pc' and 'q35'.
This patch adds some helper functions to manage the bitmasks.
The implemented features depend on both OVMF build configuration
and qemu VM configuration.
For q35 a single security feature is supported and checked: In
SMM-enabled builds the driver will verify smram is properly locked.
That test should never fail.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Konstantin Kostiuk <kkostiuk@redhat.com>
Initial-patch-by: Konstantin Kostiuk <kkostiuk@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4756
There are below updates in this patch:
1. Rename README to README.md so that it can be show as markdown
document.
2. Update some information about TDVF.
2. Fix some typo.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.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=4654
Currently, an SEV-SNP guest will terminate if it is not running at VMPL0.
The requirement for running at VMPL0 is removed if an SVSM is present.
Update the current VMPL0 check to additionally check for the presence of
an SVSM is the guest is not running at VMPL0.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Michael Roth <michael.roth@amd.com>
Cc: Min Xu <min.m.xu@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654
The SVSM specification documents an alternative method of discovery for
the SVSM using a reserved CPUID bit and a reserved MSR.
For the CPUID support, the #VC handler of an SEV-SNP guest should modify
the returned value in the EAX register for the 0x8000001f CPUID function
by setting bit 28 when an SVSM is present.
For the MSR support, new reserved MSR 0xc001f000 has been defined. A #VC
should be generated when accessing this MSR. The #VC handler is expected
to ignore writes to this MSR and return the physical calling area address
(CAA) on reads of this MSR.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Michael Roth <michael.roth@amd.com>
Cc: Min Xu <min.m.xu@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654
The RMPADJUST instruction is used to alter the VMSA attribute of a page,
but the VMSA attribute can only be changed when running at VMPL0. When
an SVSM is present, use the SVSM_CORE_CREATE_VCPU and SVSM_CORE_DELTE_VCPU
calls to add or remove the VMSA attribute on a page instead of issuing
the RMPADJUST instruction directly.
Implement the AmdSvsmSnpVmsaRmpAdjust() API to perform the proper operation
to update the VMSA attribute.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654
Similar to the Page State Change optimization added previously, also take
into account the possiblity of using the SVSM for PVALIDATE instructions.
Conditionally adjust the maximum number of entries based on how many
entries the SVSM calling area can support.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Michael Roth <michael.roth@amd.com>
Cc: Min Xu <min.m.xu@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654
The PVALIDATE instruction can only be performed at VMPL0. An SVSM will
be present when running at VMPL1 or higher.
When an SVSM is present, use the SVSM_CORE_PVALIDATE call to perform
memory validation instead of issuing the PVALIDATE instruction directly.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Heinrich Schuchardt
Gerd Hoffmann
Ceping Sun
Mike Beaton
Oliver Smith-Denny
Xianglai Li
Dionna Glaze
Chao Li
Anthony PERARD
Jason Andryuk
Min M Xu
Sami Mujawar
Ard Biesheuvel
Leif Lindholm
Dhaval
Alexey Kardashevskiy
Tobin Feldman-Fitzthum
Mike Maslenkin
Corvin Köhne
Ross Lagerwall
Jiaxin Wu
Dun Tan
Du Lin
Doug Flick
Flickdm
Sachin Ganesh
Michael Roth
Adam Dunlap
Konstantin Kostiuk
Tom Lendacky