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>
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