Add QemuCpuhpWriteCpuStatus() which will be used to update the QEMU
CPU status register. On error, it hangs in a similar fashion as
other helper functions.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Aaron Young <aaron.young@oracle.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3132
Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210312062656.2477515-4-ankur.a.arora@oracle.com>
Process fw_remove events in QemuCpuhpCollectApicIds(), and collect APIC IDs
and QEMU CPU Selectors for CPUs being hot-unplugged.
In addition, we now ignore CPUs which only have remove set. These
CPUs haven't been processed by OSPM yet.
This is based on the QEMU hot-unplug protocol documented here:
https://lore.kernel.org/qemu-devel/20201204170939.1815522-3-imammedo@redhat.com/
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Aaron Young <aaron.young@oracle.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3132
Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
Message-Id: <20210312062656.2477515-3-ankur.a.arora@oracle.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Refactor CpuHotplugMmi() to pull out the CPU hotplug logic into
ProcessHotAddedCpus(). This is in preparation for supporting CPU
hot-unplug.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Aaron Young <aaron.young@oracle.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3132
Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210312062656.2477515-2-ankur.a.arora@oracle.com>
This change added NULL MmUnblockMemoryLib instance in dsc files of
OvmfPkg to pass CI build. When SMM_REQUIRE flag is set, the library
interface is consumed by VariableSmmRuntimeDxe to better support variable
runtime cache feature.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Signed-off-by: Kun Qin <kun.q@outlook.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <MWHPR06MB31028DFAB7AE46E32E5F9F86F3969@MWHPR06MB3102.namprd06.prod.outlook.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3183
Under SEV-ES, a write to the flash device is done using a direct VMGEXIT
to perform an MMIO write. The address provided to the MMIO write must be
the physical address of the MMIO write destitnation. During boot, OVMF
runs with an identity mapped pagetable structure so that VA == PA and the
VMGEXIT MMIO write destination is just the virtual address of the flash
area address being written.
However, when the UEFI SetVirtualAddressMap() API is invoked, an identity
mapped pagetable structure may not be in place and using the virtual
address for the flash area address is no longer valid. This results in
writes to the flash not being performed successfully. This can be seen
by attempting to change the boot order under Linux. The update will
appear to be performed, based on the output of the command. But rebooting
the guest will show that the new boot order has not been set.
To remedy this, save the value of the flash base physical address before
converting the address as part of SetVirtualAddressMap(). The physical
address can then be calculated by obtaining the offset of the MMIO target
virtual address relative to the flash base virtual address and adding that
to the original flash base physical address. The resulting value produces
a successful MMIO write during runtime services.
Fixes: 437eb3f7a8
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <84a5f9161541db5aa3b57c96b737afbcb4b6189d.1611410263.git.thomas.lendacky@amd.com>
[lersek@redhat.com: SetVitualAddressMap() -> SetVirtualAddressMap() typo
fix, in both the commit message and the code comment]
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
CpuS3DataDxe allocates the "RegisterTable" and "PreSmmInitRegisterTable"
arrays in ACPI_CPU_DATA just so every processor in the system can have its
own empty register table, matched by APIC ID. This has never been useful
in practice.
Given commit e992cc3f48 ("UefiCpuPkg PiSmmCpuDxeSmm: Reduce SMRAM
consumption in CpuS3.c", 2021-01-11), simply leave both
"AcpiCpuData->RegisterTable" and "AcpiCpuData->PreSmmInitRegisterTable"
initialized to the zero address. This simplifies the driver, and saves
both normal RAM (boot services data type memory) and -- in PiSmmCpuDxeSmm
-- SMRAM.
(This simplification backs out a good chunk of commit 1158fc8e2c
("OvmfPkg/CpuS3DataDxe: enable S3 resume after CPU hotplug", 2020-03-04).
But CpuS3DataDxe still differs between UefiCpuPkg and OvmfPkg, due to the
latter supporting CPU hotplug; thus, we can't remove OvmfPkg/CpuS3DataDxe
altogether.)
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3159
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Message-Id: <20210119155440.2262-5-lersek@redhat.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Extend parameter list of PciHostBridgeUtilityGetRootBridges() with BusMin/
BusMax, so that the utility function could be compatible with ArmVirtPkg
who uses mutable bus range [BusMin, BusMax] insteand of [0, PCI_MAX_BUS].
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3059
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Signed-off-by: Jiahui Cen <cenjiahui@huawei.com>
Message-Id: <20210119011302.10908-10-cenjiahui@huawei.com>
[lersek@redhat.com: fix logging of UINTN values BusMin, BusMax]
[lersek@redhat.com: keep zeroing of (*Count) centralized]
[lersek@redhat.com: fix typos in ExtraRootBridges comment]
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
OvmfPkg/PciHostBridgeLib instance fails to list its PcdLib dependency,
both between the #include directives, and in the INF file. So let's list
the dependency.
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3059
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Julien Grall <julien@xen.org>
Signed-off-by: Jiahui Cen <cenjiahui@huawei.com>
Message-Id: <20210119011302.10908-4-cenjiahui@huawei.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
In NOOPT and DEBUG builds, if "PcdMaximumLinkedListLength" is nonzero,
then several LIST_ENTRY *node* APIs in BaseLib compare the *full* list
length against the PCD.
This turns the time complexity of node-level APIs from constant to linear,
and that of full-list manipulations from linear to quadratic.
As an example, consider the EFI_SHELL_FILE_INFO list, which is a data
structure that's widely used in the UEFI shell. I randomly extracted 5000
files from "/usr/include" on my laptop, spanning 1095 subdirectories out
of 1538, and then ran "DIR -R" in the UEFI shell on this tree. These are
the wall-clock times:
PcdMaximumLinkedListLength PcdMaximumLinkedListLength
=1,000,000 =0
-------------------------- ---------------------------
FAT 4 min 31 s 18 s
virtio-fs 5 min 13 s 1 min 33 s
Checking list lengths against an arbitrary maximum (default: 1,000,000)
seems useless even in NOOPT and DEBUG builds, while the cost is
significant; so set the PCD to 0.
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien@xen.org>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Peter Grehan <grehan@freebsd.org>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Rebecca Cran <rebecca@bsdio.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3152
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Message-Id: <20210113085453.10168-10-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Some UEFI shell commands read and write files in chunks. The chunk size is
given by "PcdShellFileOperationSize", whose default in
"ShellPkg/ShellPkg.dec" is 4KB (0x1000).
The virtio-fs daemon of QEMU advertizes a 128KB maximum buffer size by
default, for the FUSE_WRITE operation.
By raising PcdShellFileOperationSize 32-fold, the number of FUSE write
requests shrinks proportionately, when writing large files. And when a
Virtio Filesystem is not used, a 128KB chunk size is still not
particularly wasteful.
Some ad-hoc measurements on my laptop, using OVMF:
- The time it takes to copy a ~270MB file from a Virtio Filesystem to the
same Virtio Filesystem improves from ~9 seconds to ~1 second.
- The time it takes to compare two identical ~270MB files on the same
Virtio Filesystem improves from ~11 seconds to ~3 seconds.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3125
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Message-Id: <20210113085453.10168-3-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
We faced a problem with passing through a PCI device with 64GB BAR to UEFI
guest. The BAR is expectedly programmed into 64-bit PCI aperture at 64G
address which pushes physical address space to 37 bits. That is above
36-bit width that OVMF exposes currently to a guest without tweaking
PcdPciMmio64Size knob.
The reverse calculation using this knob was inhereted from QEMU-KVM
platform code where it serves the purpose of finding max accessible
physical address without necessary trusting emulated CPUID physbits value
(that could be different from host physbits). On Xen we expect to use
CPUID policy to level the data correctly to prevent situations with guest
physbits > host physbits e.g. across migrations.
The next aspect raising concern - resource consumption for DXE IPL page
tables and time required to map the whole address space in case of using
CPUID bits directly. That could be mitigated by enabling support for 1G
pages in DXE IPL configuration. 1G pages are available on most CPUs
produced in the last 10 years and those without don't have many phys bits.
Remove all the redundant code now (including PcdPciMmio64.. handling
that's not used on Xen anyway) and grab physbits directly from CPUID that
should be what baremetal UEFI systems do.
Signed-off-by: Igor Druzhinin <igor.druzhinin@citrix.com>
Message-Id: <1610509335-23314-1-git-send-email-igor.druzhinin@citrix.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Julien Grall <julien@xen.org>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
[lersek@redhat.com: fix up authorship from groups.io-mangled From line]
[lersek@redhat.com: wrap commit message at 74 characters]
Commit 55ee36b0c4
("EmbeddedPkg/RealTimeClockRuntimeDxe: Use helper functions from TimeBaseLib")
added a TimeBaseLib dependency to RealTimeClockRuntimeDxe, which now breaks
build of OvmfXen.dsc.
Add a resolution for EmbeddedPkg/Library/TimeBaseLib/TimeBaseLib.inf.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Julien Grall <julien@xen.org>
Signed-off-by: Leif Lindholm <leif@nuviainc.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108
When SEV-ES is active, and MMIO operation will trigger a #VC and the
VmgExitLib exception handler will process this MMIO operation.
A malicious hypervisor could try to extract information from encrypted
memory by setting a reserved bit in the guests nested page tables for
a non-MMIO area. This can result in the encrypted data being copied into
the GHCB shared buffer area and accessed by the hypervisor.
Prevent this by ensuring that the MMIO source/destination is un-encrypted
memory. For the APIC register space, access is allowed in general.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <0cf28470ad5e694af45f7f0b35296628f819567d.1610045305.git.thomas.lendacky@amd.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108
Protect the GHCB backup pages used by an SEV-ES guest when S3 is
supported.
Regarding the lifecycle of the GHCB backup pages:
PcdOvmfSecGhcbBackupBase
(a) when and how it is initialized after first boot of the VM
If SEV-ES is enabled, the GHCB backup pages are initialized when a
nested #VC is received during the SEC phase
[OvmfPkg/Library/VmgExitLib/SecVmgExitVcHandler.c].
(b) how it is protected from memory allocations during DXE
If S3 and SEV-ES are enabled, then InitializeRamRegions()
[OvmfPkg/PlatformPei/MemDetect.c] protects the ranges with an AcpiNVS
memory allocation HOB, in PEI.
If S3 is disabled, then these ranges are not protected. PEI switches to
the GHCB backup pages in permanent PEI memory and DXE will use these
PEI GHCB backup pages, so we don't have to preserve
PcdOvmfSecGhcbBackupBase.
(c) how it is protected from the OS
If S3 is enabled, then (b) reserves it from the OS too.
If S3 is disabled, then the range needs no protection.
(d) how it is accessed on the S3 resume path
It is rewritten same as in (a), which is fine because (b) reserved it.
(e) how it is accessed on the warm reset path
It is rewritten same as in (a).
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Julien Grall <julien@xen.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <119102a3d14caa70d81aee334a2e0f3f925e1a60.1610045305.git.thomas.lendacky@amd.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108
In order to be able to issue messages or make interface calls that cause
another #VC (e.g. GetLocalApicBaseAddress () issues RDMSR), add support
for nested #VCs.
In order to support nested #VCs, GHCB backup pages are required. If a #VC
is received while currently processing a #VC, a backup of the current GHCB
content is made. This allows the #VC handler to continue processing the
new #VC. Upon completion of the new #VC, the GHCB is restored from the
backup page. The #VC recursion level is tracked in the per-vCPU variable
area.
Support is added to handle up to one nested #VC (or two #VCs total). If
a second nested #VC is encountered, an ASSERT will be issued and the vCPU
will enter CpuDeadLoop ().
For SEC, the GHCB backup pages are reserved in the OvmfPkgX64.fdf memory
layout, with two new fixed PCDs to provide the address and size of the
backup area.
For PEI/DXE, the GHCB backup pages are allocated as boot services pages
using the memory allocation library.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <ac2e8203fc41a351b43f60d68bdad6b57c4fb106.1610045305.git.thomas.lendacky@amd.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108
Update the MemEncryptSevLib library to include an interface that can
report the encryption state on a range of memory. The values will
represent the range as being unencrypted, encrypted, a mix of unencrypted
and encrypted, and error (e.g. ranges that aren't mapped).
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <0d98f4d42a2b67310c29bac7bcdcf1eda6835847.1610045305.git.thomas.lendacky@amd.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108
In preparation for a new interface to be added to the MemEncryptSevLib
library that will be used in SEC, create an SEC version of the library.
This requires the creation of SEC specific files.
Some of the current MemEncryptSevLib functions perform memory allocations
which cannot be performed in SEC, so these interfaces will return an error
during SEC. Also, the current MemEncryptSevLib library uses some static
variables to optimize access to variables, which cannot be used in SEC.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <bc7fa76cc23784ab3f37356b6c10dfec61942c38.1610045305.git.thomas.lendacky@amd.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108
Creating an SEC version of the library requires renaming an existing file
which will result in the existing code failing ECC. Prior to renaming the
existing file, fix the coding style to avoid the ECC failure.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <f765d867da4a703e0a0db35e26515a911482fd40.1610045305.git.thomas.lendacky@amd.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108
Check the DR7 cached indicator against a specific value. This makes it
harder for a hypervisor to just write random data into that field in an
attempt to use an invalid DR7 value.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <65157c1155a9c058c43678400dfc0b486e327a3e.1610045305.git.thomas.lendacky@amd.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108
The PCIe MMCONFIG range should be treated as an MMIO range. However,
there is a comment in the code explaining why AddIoMemoryBaseSizeHob()
is not called. The AmdSevDxe walks the GCD map looking for MemoryMappedIo
or NonExistent type memory and will clear the encryption bit for these
ranges.
Since the MMCONFIG range does not have one of these types, the encryption
bit is not cleared for this range. Add support to detect the presence of
the MMCONFIG range and clear the encryption bit. This will be needed for
follow-on support that will validate that MMIO is not being performed to
an encrypted address range under SEV-ES.
Even though the encryption bit was set for this range, this still worked
under both SEV and SEV-ES because the address range is marked by the
hypervisor as MMIO in the nested page tables:
- For SEV, access to this address range triggers a nested page fault (NPF)
and the hardware supplies the guest physical address (GPA) in the VMCB's
EXITINFO2 field as part of the exit information. However, the encryption
bit is not set in the GPA, so the hypervisor can process the request
without any issues.
- For SEV-ES, access to this address range triggers a #VC. Since OVMF runs
identity mapped (VA == PA), the virtual address is used to avoid the
lookup of the physical address. The virtual address does not have the
encryption bit set, so the hypervisor can process the request without
any issues.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <711ae2dcb6cb29e4c60862c18330cff627269b81.1610045305.git.thomas.lendacky@amd.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108
The early assembler code performs validation for some of the SEV-related
information, specifically the encryption bit position. The new
MemEncryptSevGetEncryptionMask() interface provides access to this
validated value.
To ensure that we always use a validated encryption mask for an SEV-ES
guest, update all locations that use CPUID to calculate the encryption
mask to use the new interface.
Also, clean up some call areas where extra masking was being performed
and where a function call was being used instead of the local variable
that was just set using the function.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Rebecca Cran <rebecca@bsdio.com>
Cc: Peter Grehan <grehan@freebsd.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Julien Grall <julien@xen.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <9de678c0d66443c6cc33e004a4cac0a0223c2ebc.1610045305.git.thomas.lendacky@amd.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108
To ensure that we always use a validated encryption mask for an SEV-ES
guest, create a new interface in the MemEncryptSevLib library to return
the encryption mask. This can be used in place of the multiple locations
where CPUID is used to retrieve the value (which would require validation
again) and allows the validated mask to be returned.
The PEI phase will use the value from the SEV-ES work area. Since the
SEV-ES work area isn't valid in the DXE phase, the DXE phase will use the
PcdPteMemoryEncryptionAddressOrMask PCD which is set during PEI.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Rebecca Cran <rebecca@bsdio.com>
Cc: Peter Grehan <grehan@freebsd.org>
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Julien Grall <julien@xen.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <e12044dc01b21e6fc2e9535760ddf3a38a142a71.1610045305.git.thomas.lendacky@amd.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108
The early assembler code performs validation for some of the SEV-related
information, specifically the encryption bit position. To avoid having to
re-validate the encryption bit position as the system proceeds through its
boot phases, save the validated encryption bit position in the SEV-ES work
area for use by later phases.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <2609724859cf21f0c6d45bc323e94465dca4e621.1610045305.git.thomas.lendacky@amd.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108
If a hypervisor incorrectly reports through CPUID that SEV-ES is not
active, ensure that a #VC exception was not taken. If it is found that
a #VC was taken, then the code enters a HLT loop.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <afa2030b95b852313b13982df82d472187e59b92.1610045305.git.thomas.lendacky@amd.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108
To help mitigate against ROP attacks, add some checks to validate the
encryption bit position that is reported by the hypervisor.
The first check is to ensure that the hypervisor reports a bit position
above bit 31. After extracting the encryption bit position from the CPUID
information, the code checks that the value is above 31. If the value is
not above 31, then the bit position is not valid, so the code enters a
HLT loop.
The second check is specific to SEV-ES guests and is a two step process.
The first step will obtain random data using RDRAND and store that data to
memory before paging is enabled. When paging is not enabled, all writes to
memory are encrypted. The random data is maintained in registers, which
are protected. The second step is that, after enabling paging, the random
data in memory is compared to the register contents. If they don't match,
then the reported bit position is not valid, so the code enters a HLT
loop.
The third check is after switching to 64-bit long mode. Use the fact that
instruction fetches are automatically decrypted, while a memory fetch is
decrypted only if the encryption bit is set in the page table. By
comparing the bytes of an instruction fetch against a memory read of that
same instruction, the encryption bit position can be validated. If the
compare is not equal, then SEV/SEV-ES is active but the reported bit
position is not valid, so the code enters a HLT loop.
To keep the changes local to the OvmfPkg, an OvmfPkg version of the
Flat32ToFlat64.asm file has been created based on the UefiCpuPkg file
UefiCpuPkg/ResetVector/Vtf0/Ia32/Flat32ToFlat64.asm.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <cb9c5ab23ab02096cd964ed64115046cc706ce67.1610045305.git.thomas.lendacky@amd.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108
In order to allow for the SEV-ES workarea to be used for other purposes
and by other files, move the definition into the BaseMemEncryptSevLib
header file, MemEncryptSevLib.h.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <07d66f3384bd54da97d540e89b9f3473a6d17231.1610045305.git.thomas.lendacky@amd.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108
Simplify and consolidate the SEV and SEV-ES checks into a single routine.
This new routine will use CPUID to check for the appropriate CPUID leaves
and the required values, as well as read the non-interceptable SEV status
MSR (0xc0010131) to check SEV and SEV-ES enablement.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <43a660624c32b5f6c2610bf42ee39101c21aff68.1610045305.git.thomas.lendacky@amd.com>
EmbeddedPkg/TimeBaseLib provides a verification function called
IsTimeValid(), for enforcing the UEFI spec requirements on an EFI_TIME
object.
When EFI_FILE_PROTOCOL.SetInfo() is called in order to update the
timestamps on the file, let's invoke IsTimeValid() first, before passing
the new EFI_FILE_INFO.{CreateTime,LastAccessTime,ModificationTime} values
to EfiTimeToEpoch().
This patch is not expected to make a practical difference, but it's better
to ascertain the preconditions of EfiTimeToEpoch() on the
EFI_FILE_PROTOCOL.SetInfo() caller. The FAT driver (EnhancedFatDxe) has a
similar check, namely in FatSetFileInfo() -> FatIsValidTime().
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210107095051.22715-1-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Using the functions introduced previously, we can now update file
attributes in VirtioFsSimpleFileSetInfo().
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201216211125.19496-49-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Using the functions introduced previously, we can now implement the rename
operation in VirtioFsSimpleFileSetInfo().
Attribute updates come later.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201216211125.19496-44-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
The EFI_FILE_PROTOCOL.SetInfo() member is somewhat under-specified; one of
its modes of operation is renaming/moving the file.
In order to create the destination pathname in canonical format, 2*2=4
cases have to be considered. For the sake of discussion, assume the
current canonical pathname of a VIRTIO_FS_FILE is "/home/user/f1.txt".
Then, consider the following rename/move requests from
EFI_FILE_PROTOCOL.SetInfo():
Destination requested Destination Move into Destination in
by SetInfo() relative? directory? canonical format
--------------------- ----------- ---------- -----------------------
L"\\dir\\f2.txt" no no "/dir/f2.txt"
L"\\dir\\" no yes "/dir/f1.txt"
L"dir\\f2.txt" yes no "/home/user/dir/f2.txt"
L"dir\\" yes yes "/home/user/dir/f1.txt"
Add the VirtioFsComposeRenameDestination() function, for composing the
last column from the current canonical pathname and the SetInfo() input.
The function works on the following principles:
- The prefix of the destination path is "/", if the SetInfo() rename
request is absolute.
Otherwise, the dest prefix is the "current directory" (the most specific
parent directory) of the original pathname (in the above example,
"/home/user").
- The suffix of the destination path is precisely the SetInfo() request
string, if the "move into directory" convenience format -- the trailing
backslash -- is not used. (In the above example, L"\\dir\\f2.txt" and
L"dir\\f2.txt".)
Otherwise, the suffix is the SetInfo() request, plus the original
basename (in the above example, L"\\dir\\f1.txt" and L"dir\\f1.txt").
- The complete destination is created by fusing the dest prefix and the
dest suffix, using the VirtioFsAppendPath() function.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201216211125.19496-43-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
The least complicated third of EFI_FILE_PROTOCOL.SetInfo() is to handle
the EFI_FILE_SYSTEM_INFO and EFI_FILE_SYSTEM_VOLUME_LABEL setting
requests. Both of those can only change the volume label -- which the
Virtio Filesystem device does not support.
Verify the input for well-formedness, and report success only if the
volume label is being set to its current value.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201216211125.19496-41-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Using the functions introduced previously, we can now implement
VirtioFsSimpleFileWrite().
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201216211125.19496-40-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Add the VirtioFsFuseWrite() function, for sending the FUSE_WRITE command
to the Virtio Filesystem device.
(For avoiding oversized FUSE_WRITE commands, save the maximum write buffer
size that is advertized by the FUSE server, in the session init code.)
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201216211125.19496-39-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
For directories, implement EFI_FILE_PROTOCOL.Flush() by sending the
FUSE_FSYNCDIR command to the Virtio Filesystem device.
For regular files, send FUSE_FLUSH, followed by FUSE_FSYNC.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201216211125.19496-38-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Using the functions introduced previously, we can now implement
VirtioFsSimpleFileRead() for directories as well.
This patch completes the read-only support for virtio-fs. Commands like
"TYPE" and "DIR" work in the UEFI shell.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201216211125.19496-37-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
For reading through a directory stream with tolerable performance, we'll
have to call FUSE_READDIRPLUS each time with such a buffer that can
deliver a good number of variable size records
(VIRTIO_FS_FUSE_DIRENTPLUS_RESPONSE elements). Every time we'll do that,
we'll turn the whole bunch into an array of EFI_FILE_INFOs immediately.
EFI_FILE_PROTOCOL.Read() invocations (on directories) will be served from
this EFI_FILE_INFO cache.
Add the fields for the EFI_FILE_INFO cache to VIRTIO_FS_FILE:
- initialize them in Open() and OpenVolume(),
- release the cache in Close() and Delete(),
- also release the cache when the directory is rewound, in SetPosition().
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201216211125.19496-36-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Introduce the VirtioFsFuseDirentPlusToEfiFileInfo() function, for
converting the VIRTIO_FS_FUSE_DIRENTPLUS_RESPONSE filename byte array to
EFI_FILE_INFO.
This new function updates those EFI_FILE_INFO fields (Size, FileName) that
the earlier helper function VirtioFsFuseAttrToEfiFileInfo() does not set.
Both functions together will be able to fill in EFI_FILE_INFO completely,
from FUSE_READDIRPLUS.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201216211125.19496-35-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Using the functions introduced previously, we can now implement
VirtioFsSimpleFileRead(); for regular files at first.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201216211125.19496-34-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Add the VirtioFsFuseReadFileOrDir() function, for sending the FUSE_READ or
FUSE_READDIRPLUS command to the Virtio Filesystem device.
Parsing the structured FUSE_READDIRPLUS output is complex, and cannot be
integrated into the wrapper function. Given that fact, FUSE_READ and
FUSE_READDIRPLUS turn out to need identical low-level handling, except for
the opcode. Hence the shared wrapper function.
(It's prudent to verify whether the FUSE server supports FUSE_READDIRPLUS,
so update the session init code accordingly.)
This is the first FUSE request wrapper function that deals with a variable
size tail buffer.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201216211125.19496-33-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Using the functions introduced previously, we can now implement
VirtioFsSimpleFileGetPosition() and VirtioFsSimpleFileSetPosition().
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201216211125.19496-32-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Using the functions introduced previously, we can now implement
VirtioFsSimpleFileGetInfo().
This allows the "VOL" command to work in the UEFI shell.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201216211125.19496-31-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
The EFI_FILE_INFO structure, which is output by
EFI_FILE_PROTOCOL.GetInfo(), ends with a flexible CHAR16 array called
"FileName". Add the VirtioFsGetBasename() function, for determining the
required array size, and for filling the array as well.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201216211125.19496-30-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
At this point, the infrastructure is available for looking up the directly
containing directory of the file in EFI_FILE_PROTOCOL.Delete(), and to
remove the file in that directory by last pathname component. Do so.
The "RM" UEFI shell command will start working only later in the series;
the shell needs more EFI_FILE_PROTOCOL members to function before it calls
Delete().
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201216211125.19496-28-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Using the functions introduced previously, we can now implement
VirtioFsSimpleFileOpen().
This lets the "MKDIR" command to work in the UEFI shell, for example.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201216211125.19496-27-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
The FUSE_UNLINK and FUSE_RMDIR commands only differ in the opcode. Add a
common function for wrapping both.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201216211125.19496-25-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Given a canonical pathname (as defined by VirtioFsAppendPath()), different
from "/", introduce a helper function for:
- looking up the NodeId of the most specific parent directory, and
- exposing the last component stand-alone (which is therefore a direct
child of said parent directory).
This splitting operation will be necessary in multiple subsequent patches.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201216211125.19496-24-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Introduce the VirtioFsFuseAttrToEfiFileInfo() function, for converting
FUSE inode attributes to EFI_FILE_INFO.
The EpochToEfiTime() function from EmbeddedPkg's TimeBaseLib proves
invaluable for converting the file access times.
This is the first time we consume TimeBaseLib in OvmfPkg, so add the
necessary lib class resolution. We need not modify any ArmVirtPkg DSC
files: see commit af5fed90bf ("ArmPlatformPkg,ArmVirtPkg: delete
redundant PL031 functions", 2017-05-10).
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201216211125.19496-22-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Add a canonical pathname field to VIRTIO_FS_FILE.
Initialize the new field in EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.OpenVolume().
Release the new field in EFI_FILE_PROTOCOL.Close() and
EFI_FILE_PROTOCOL.Delete().
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201216211125.19496-18-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
EFI_FILE_PROTOCOL.Open() -- for opening files -- and
EFI_FILE_PROTOCOL.SetInfo() -- for renaming files -- will require us to
append a relative UEFI pathname to an absolute base pathname. In turn,
components of the resultant pathnames will have to be sent to virtiofsd,
which does not consume UEFI-style pathnames.
We're going to maintain the base pathnames in canonical POSIX format:
- absolute (starts with "/"),
- dot (.) and dot-dot (..) components resolved/removed,
- uses forward slashes,
- sequences of slashes collapsed,
- printable ASCII character set,
- CHAR8 encoding,
- no trailing slash except for the root directory itself,
- length at most VIRTIO_FS_MAX_PATHNAME_LENGTH.
Add a helper function that can append a UEFI pathname to such a base
pathname, and produce the result in conformance with the same invariants.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201216211125.19496-17-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
The two member functions that free the EFI_FILE_PROTOCOL object are
Close() and Delete(). Before we create VIRTIO_FS_FILE objects with
EFI_FILE_PROTOCOL.Open() later in this patch series, extend each of these
"destructor" functions to get rid of the FuseHandle and NodeId resources
properly -- in a way that matches each function's own purpose.
For the time being, VirtioFsSimpleFileDelete() only gets a reminder about
its core task (namely, removing the file), as the needed machinery will
become only later. But we can already outline the "task list", and deal
with the FuseHandle and NodeId resources. The "task list" of
VirtioFsSimpleFileDelete() is different from that of
VirtioFsSimpleFileClose(), thus both destructors diverge at this point.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201216211125.19496-16-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
The FUSE_FSYNC and FUSE_FSYNCDIR commands only differ in the opcode. Add a
common function for wrapping both.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201216211125.19496-14-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Add the VirtioFsFuseForget() function, for sending the FUSE_FORGET command
to the Virtio Filesystem device.
This is an unusual command in that it doesn't generate any response from
the FUSE server.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201216211125.19496-13-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
With the help of the VirtioFsFuseOpenDir() and
VirtioFsFuseReleaseFileOrDir() functions introduced previously, we can now
open and close the root directory. So let's implement
EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.OpenVolume().
OpenVolume() creates a new EFI_FILE_PROTOCOL object -- a reference to the
root directory of the filesystem. Thus, we have to start tracking
references to EFI_SIMPLE_FILE_SYSTEM_PROTOCOL, lest we unbind the
virtio-fs device while files are open.
There are two methods that release an EFI_FILE_PROTOCOL object: the
Close() and the Delete() member functions. In particular, they are not
allowed to fail with regard to resource management -- they must release
resources unconditionally. Thus, for rolling back the resource accounting
that we do in EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.OpenVolume(), we have to
implement the first versions of EFI_FILE_PROTOCOL.Close() and
EFI_FILE_PROTOCOL.Delete() in this patch as well.
With this patch applied, the UEFI shell can enter the root directory of
the Virtio Filesystem (such as with the "FS3:" shell command), and the
"DIR" shell command exercises FUSE_OPENDIR and FUSE_RELEASEDIR, according
to the virtiofsd log. The "DIR" command reports the root directory as if
it were empty; probably because at this time, we only allow the shell to
open and to close the root directory, but not to read it.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201216211125.19496-12-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
The FUSE_RELEASE and FUSE_RELEASEDIR commands only differ in the opcode.
Add a common function called VirtioFsFuseReleaseFileOrDir() for sending
either command.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201216211125.19496-11-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Submit the FUSE_INIT request to the Virtio Filesystem device, for starting
the FUSE session.
The FUSE_INIT request is logged by the virtio-fs daemon, with this patch
applied, when (for example) using the "CONNECT" UEFI shell command.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201216211125.19496-9-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
The VirtioFsFuseCheckResponse() function dedicates the EFI_DEVICE_ERROR
status code to the case when the Virtio Filesystem device explicitly
returns an error via the "VIRTIO_FS_FUSE_RESPONSE.Error" field.
Said field effectively carries a Linux "errno" value. Introduce a helper
function for mapping "errno" values to (hopefully) reasonable EFI_STATUS
codes. This way we'll be able to propagate "errno" values as EFI_STATUS
return codes along the UEFI call stack -- in some detail anyway.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201216211125.19496-8-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Introduce the VIRTIO_FS_FUSE_REQUEST and VIRTIO_FS_FUSE_RESPONSE
structures, which are the common headers for the various FUSE
request/response structures.
Introduce the VirtioFsFuseNewRequest() helper function for populating
VIRTIO_FS_FUSE_REQUEST, from parameters and from a VIRTIO_FS-level request
counter.
Introduce the VirtioFsFuseCheckResponse() helper function for verifying
most FUSE response types that begin with the VIRTIO_FS_FUSE_RESPONSE
header.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201216211125.19496-7-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
In preparation for the variously structured FUSE request/response
exchanges that virtio-fs uses, introduce a scatter-gather list data type.
This will let us express FUSE request-response pairs flexibly.
Add a function for validating whether a (request buffer list, response
buffer list) pair is well-formed, and supported by the Virtio Filesystem
device's queue depth.
Add another function for mapping and submitting a validated pair of
scatter-gather lists to the Virtio Filesystem device.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201216211125.19496-6-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
[lersek@redhat.com: suppress useless VS2019 warning about signed/unsigned
comparison in VirtioFsSgListsValidate()]
Add the VirtioFsInit(), VirtioFsUninit(), and VirtioFsExitBoot()
functions.
In VirtioFsInit():
- Verify the host-side config of the virtio-fs device.
- Save the filesystem label ("tag") for later, from the configuration area
of the virtio-fs device.
- Save the virtio queue size for later as well.
- Set up the virtio ring for sending requests.
In VirtioFsUninit():
- Reset the device.
- Tear down the virtio ring.
In VirtioFsExitBoot():
- Reset the device.
With this patch, the UEFI connect / disconnect controller operations
involve virtio setup / teardown; they are visible in the virtio-fs
daemon's log file. The virtiofsd log also confirms the device reset in
VirtioFsExitBoot(), when an OS is booted while the virtio-fs device is
bound.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201216211125.19496-5-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Complete the Supported, Start, and Stop member functions of
EFI_DRIVER_BINDING_PROTOCOL sufficiently for exercising the UEFI driver
model:
- bind virtio-fs devices,
- produce placeholder EFI_SIMPLE_FILE_SYSTEM_PROTOCOL instances on them.
On the "TO_START" (= Virtio) side, the VirtioFsBindingSupported() function
verifies the Virtio subsystem ID for the virtio-fs device (decimal 26 --
see
<https://github.com/oasis-tcs/virtio-spec/blob/87fa6b5d8155/virtio-fs.tex>).
Beyond that, no actual Virtio setup is performed for now. Those bits are
going to be implemented later in this series.
On the "BY_START" (= UEFI filesystem) side, the VirtioFsOpenVolume()
function -- which is the sole EFI_SIMPLE_FILE_SYSTEM_PROTOCOL member
function -- is a stub; it always returns EFI_NO_MEDIA, for now.
The "CONNECT", "DISCONNECT", and "MAP -R" UEFI Shell commands can be used
to test this patch.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201216211125.19496-4-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
The purpose of the driver is to ease file exchange (file sharing) between
the guest firmware and the virtualization host. The driver is supposed to
interoperate with QEMU's "virtiofsd" (Virtio Filesystem Daemon).
References:
- https://virtio-fs.gitlab.io/
- https://libvirt.org/kbase/virtiofs.html
VirtioFsDxe will bind virtio-fs devices, and produce
EFI_SIMPLE_FILE_SYSTEM_PROTOCOL instances on them.
In the longer term, assuming QEMU will create "bootorder" fw_cfg file
entries for virtio-fs devices, booting guest OSes from host-side
directories should become possible (dependent on the matching
QemuBootOrderLib enhancement).
Add the skeleton of the driver. Install EFI_DRIVER_BINDING_PROTOCOL with
stub member functions. Install EFI_COMPONENT_NAME2_PROTOCOL with final
member functions. This suffices for the DRIVERS command in the UEFI Shell
to list the driver with a human-readable name.
The file permission model is described immediately in the INF file as a
comment block, for future reference.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201216211125.19496-2-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
This patch fixes an issue with the current programming of the i440fx
PCI Interrupt routing assignment.
Explanation by Laszlo Ersek:
(1) The rotating pattern is a map:
(slot, function) --> (interrupt link) [LNKA..LNKD]
(more precisely, it is a pattern from (slot, pin) to (interrupt link),
but function<->pin is an identity mapping in the QEMU hardware, so we
can just use (slot, function) rather than (slot, pin) on the left hand
side. But I digress.)
The ACPI _PRT object is generated by QEMU; it describes this map.
(2) Another map is
(interrupt link) --> { set of possible interrupt numbers,
for this link }
This map is given by the LNK[A..D] ACPI objects, also given by QEMU.
(3) What the firmware is expected to do is:
(3a) for each interrupt link, select an *actual* interrupt from the set
that's possible for that link, yielding a deterministic map
(interrupt link) --> (actual interrupt number)
and
(3b) for each PCI device/function with an interrupt pin, resolve the
(slot, function) --> (interrupt link) --> (actual interrupt number)
functional composition, and program the result into the Interrupt Line
register of the device.
In OVMF, we do not parse the rotating map described under (1) from
QEMU's _PRT object. Instead, we duplicate the code. This is not a
problem.
In OVMF, we also do not parse the map described under (2) from QEMU's
ACPI content. Instead, we pick a specific selection (3a) that we
"apriori" know satisfies (2). This is also not a problem. OVMF's
particular selection is the PciHostIrqs table.
(
Table (2) from QEMU is
LNKA -> { 5, 10, 11 }
LNKB -> { 5, 10, 11 }
LNKC -> { 5, 10, 11 }
LNKD -> { 5, 10, 11 }
and our specific pick in OVMF, in the PciHostIrqs table, is
LNKA -> 10
LNKB -> 10
LNKC -> 11
LNKD -> 11
)
In OVMF, we also cover step (3b), in the SetPciIntLine() function.
What's missing in OVMF -- and what this patch corrects -- is that we
currently fail to program our selection for table (3) into the hardware.
We pick a specific LNKx->IRQ# mapping for each interrupt link, and we
correctly program the PCI Interrupt Line registers through those
link-to-IRQ mappings -- but we don't tell the hardware about the
link-to-IRQ mappings. More precisely, we program such a link-to-IRQ
mapping table into the hardware that is then not matched by the mapping
we use for programming the PCI device/function interrupt lines. As a
result, some PCI Interrupt Line registers will have impossible values --
a given (slot, function) may use a particular link, but also report an
interrupt number that was never picked for that link.
Output of Linux PCI Interrupt Links for i440fx before the patch:
[ 0.327305] ACPI: PCI Interrupt Link [LNKA] (IRQs 5 10 *11)
[ 0.327944] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 10 *11)
[ 0.328582] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 *10 11)
[ 0.329208] ACPI: PCI Interrupt Link [LNKD] (IRQs 5 *10 11)
[ 0.329807] ACPI: PCI Interrupt Link [LNKS] (IRQs *9)
after the patch:
[ 0.327292] ACPI: PCI Interrupt Link [LNKA] (IRQs 5 *10 11)
[ 0.327934] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11)
[ 0.328564] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11)
[ 0.329195] ACPI: PCI Interrupt Link [LNKD] (IRQs 5 10 *11)
[ 0.329785] ACPI: PCI Interrupt Link [LNKS] (IRQs *9)
Output of Linux PCI Interrupt Links for q35 before the patch:
[ 0.307474] ACPI: PCI Interrupt Link [LNKA] (IRQs 5 *10 11)
[ 0.308027] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11)
[ 0.308764] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11)
[ 0.309310] ACPI: PCI Interrupt Link [LNKD] (IRQs 5 10 *11)
[ 0.309853] ACPI: PCI Interrupt Link [LNKE] (IRQs 5 *10 11)
[ 0.310508] ACPI: PCI Interrupt Link [LNKF] (IRQs 5 *10 11)
[ 0.311051] ACPI: PCI Interrupt Link [LNKG] (IRQs 5 10 *11)
[ 0.311589] ACPI: PCI Interrupt Link [LNKH] (IRQs 5 10 *11)
after the patch:
[ 0.301991] ACPI: PCI Interrupt Link [LNKA] (IRQs 5 *10 11)
[ 0.302833] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11)
[ 0.303354] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11)
[ 0.303873] ACPI: PCI Interrupt Link [LNKD] (IRQs 5 10 *11)
[ 0.304399] ACPI: PCI Interrupt Link [LNKE] (IRQs 5 *10 11)
[ 0.304918] ACPI: PCI Interrupt Link [LNKF] (IRQs 5 *10 11)
[ 0.305436] ACPI: PCI Interrupt Link [LNKG] (IRQs 5 10 *11)
[ 0.305954] ACPI: PCI Interrupt Link [LNKH] (IRQs 5 10 *11)
Signed-off-by: Hendrik Borghorst <hborghor@amazon.de>
Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
Message-Id: <8dbedc4c7a1c3fd390aca915270814e3b35e13a5.camel@amazon.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
It is anticipated that this part of the code will work for both Intel
TDX and AMD SEV, so remove the SEV specific naming and change to
ConfidentialComputing as a more architecture neutral prefix. Apart
from the symbol rename, there are no code changes.
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Message-Id: <20201216014146.2229-3-jejb@linux.ibm.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Although the SEV secret location must always be below 4GB, the same is
not necessarily true for Intel TDX, so change the configuration table
to contain a pair of UINT64 parameters instead of UINT32 so that any X64
location can be represented.
Signed-off-by: James Bottomley <jejb@linux.ibm.com>
Message-Id: <20201216014146.2229-2-jejb@linux.ibm.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
"vm_image: 'ubuntu-latest'" now refers to Ubuntu Focal (20.04LTS), not
Ubuntu Bionic (18.04LTS), according to
<https://github.com/actions/virtual-environments/issues/1816>.
In Focal, the "qemu" package is a dummy package with no dependencies, and
so the actual emulators are not pulled in. Compare:
https://packages.ubuntu.com/bionic/qemuhttps://packages.ubuntu.com/focal/qemu
This causes CI runs to fail.
It would be best to switch to the "qemu-system" package name, which
continues to depend on the emulators:
https://packages.ubuntu.com/bionic/qemu-systemhttps://packages.ubuntu.com/focal/qemu-system
However, while that package does make the emulators available, the
emulators crash. So for now, stick with the previous Ubuntu environment,
which continues to be supported, per
<https://github.com/actions/virtual-environments/issues/1816>.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201217204049.26817-3-lersek@redhat.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Now that the secret area is protected by a boot time HOB, extract its
location details into a configuration table referenced by
gSevLaunchSecretGuid so the boot loader or OS can locate it before a
call to ExitBootServices().
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3077
Signed-off-by: James Bottomley <jejb@linux.ibm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201130202819.3910-7-jejb@linux.ibm.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
[lersek@redhat.com: fix indentation of InstallConfigurationTable() args]
Create a one page secret area in the MEMFD and reserve the area with a
boot time HOB.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3077
Signed-off-by: James Bottomley <jejb@linux.ibm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201130202819.3910-6-jejb@linux.ibm.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
[lersek@redhat.com: s/protect/reserve/g in the commit message, at Ard's
and James's suggestion]
SEV needs an area to place an injected secret where OVMF can find it
and pass it up as a ConfigurationTable. This patch implements the
area itself as an addition to the SEV enhanced reset vector table using
an additional guid (4c2eb361-7d9b-4cc3-8081-127c90d3d294).
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3077
Signed-off-by: James Bottomley <jejb@linux.ibm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201130202819.3910-5-jejb@linux.ibm.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
[lersek@redhat.com: fix typo in "ResetVectorVtf0.asm" comments]
This is used to package up the grub bootloader into a firmware volume
where it can be executed as a shell like the UEFI Shell. Grub itself
is built as a minimal entity into a Fv and then added as a boot
option. By default the UEFI shell isn't built but for debugging
purposes it can be enabled and will then be presented as a boot option
(This should never be allowed for secure boot in an external data
centre but may be useful for local debugging). Finally all other boot
options except grub and possibly the shell are stripped and the boot
timeout forced to 0 so the system will not enter a setup menu and will
only boot to grub. This is done by copying the
Library/PlatformBootManagerLib into Library/PlatformBootManagerLibGrub
and then customizing it.
Boot failure is fatal to try to prevent secret theft.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3077
Signed-off-by: James Bottomley <jejb@linux.ibm.com>
Message-Id: <20201130202819.3910-4-jejb@linux.ibm.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
[lersek@redhat.com: replace local variable initialization with assignment]
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
[lersek@redhat.com: squash 'OvmfPkg: add "gGrubFileGuid=Grub" to
GuidCheck.IgnoreDuplicates', reviewed stand-alone by Phil (msgid
<e6eae551-8563-ccfb-5547-7a97da6d46e5@redhat.com>) and Ard (msgid
<10aeda37-def6-d9a4-6e02-4c66c1492f57@arm.com>)]
This commit represents the file copied from OvmfPkgX64 with minor
changes to change the build name.
This package will form the basis for adding Sev specific features.
Since everything must go into a single rom file for attestation, the
separated build of code and variables is eliminated.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3077
Signed-off-by: James Bottomley <jejb@linux.ibm.com>
Message-Id: <20201130202819.3910-3-jejb@linux.ibm.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Convert the current ES reset block structure to an extensible guid
based structure by appending a header and length, which allow for
multiple guid based data packets to be inserted.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3077
Signed-off-by: James Bottomley <jejb@linux.ibm.com>
Message-Id: <20201130202819.3910-2-jejb@linux.ibm.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Fix ordering of includes, sources, libraries etc.
Remove leading/trailing underscores from include guards.
Change INF and DSC version numbers to be decimal.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Message-Id: <20201130053412.2-6-rebecca@bsdio.com>
Acked-by: Peter Grehan <grehan@freebsd.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Build-tested-by: Laszlo Ersek <lersek@redhat.com>
There were some problems with the formatting and style that made the
file difficult to read.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Message-Id: <20201130053412.2-5-rebecca@bsdio.com>
Acked-by: Peter Grehan <grehan@freebsd.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Build-tested-by: Laszlo Ersek <lersek@redhat.com>
Fix the order of libraries and update INF_VERSION to 1.29.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Message-Id: <20201130053412.2-4-rebecca@bsdio.com>
Acked-by: Peter Grehan <grehan@freebsd.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Build-tested-by: Laszlo Ersek <lersek@redhat.com>
The code style in Library/BhyveFwCtlLib/BhyveFwCtlLib.c was very
inconsistent. Fix it to pass the ECC tool checks by typedef'ing
structs, and improve indentation.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Message-Id: <20201130053412.2-3-rebecca@bsdio.com>
Acked-by: Peter Grehan <grehan@freebsd.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Build-tested-by: Laszlo Ersek <lersek@redhat.com>
Update BhyveFwCtlLib.c to fix problems with UINT32/UINTN types that
prevented Bhyve from building with VS2019.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Message-Id: <20201130053412.2-2-rebecca@bsdio.com>
Acked-by: Peter Grehan <grehan@freebsd.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Build-tested-by: Laszlo Ersek <lersek@redhat.com>
Copy UefiCpuPkg/ResetVector/Vtf0/Ia16/Real16ToFlat32.asm to
OvmfPkg/Bhyve/ResetVector/Ia16, with one change, as has also been
made in XenResetVector:
- SEC_DEFAULT_CR0: enable cache (bit 30 or CD set to 0)
With the CD bit set to 1, this has the downside on AMD systems of
actually running with the cache disabled, which slows the entire system
to a crawl.
There's no need for this bit to be set in virtualized
environments.
This patch reapplies the change from the freebsd uefi-edk2 repo at
08c00f4e8d
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Peter Grehan <grehan@freebsd.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201124005733.18107-4-rebecca@bsdio.com>
On bhyve, either an Intel or AMD host bridge can be specified, with the
default being Intel.
Both are identical, except the AMD one uses a PCI vendor ID of AMD.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Peter Grehan <grehan@freebsd.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201124005733.18107-3-rebecca@bsdio.com>
Install the 2020.08.14 release of QEMU for Windows.
The QEMU release from 2020.11.20 is installed into the incorrect
directory and is causing EDK II CI failures in the run to shell
step.
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3003
There is a plan to make MD5 disable as default.
The new MACRO ENABLE_MD5_DEPRECATED_INTERFACES
would be introduced to enable MD5. Make the
definition ahead of the change to avoid build
error after the MACRO changed.
Enable iSCSI.
Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Message-Id: <20201112055558.2348-12-zhichao.gao@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Build-tested-by: Laszlo Ersek <lersek@redhat.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3003
There is a plan to make MD5 disable as default.
The new MACRO ENABLE_MD5_DEPRECATED_INTERFACES
would be introduced to enable MD5. Make the
definition ahead of the change to avoid build
error after the MACRO changed.
Enable iSCSI.
Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Message-Id: <20201112055558.2348-11-zhichao.gao@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Build-tested-by: Laszlo Ersek <lersek@redhat.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3003
There is a plan to make MD5 disable as default.
The new MACRO ENABLE_MD5_DEPRECATED_INTERFACES
would be introduced to enable MD5. Make the
definition ahead of the change to avoid build
error after the MACRO changed.
Enable iSCSI.
Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Message-Id: <20201112055558.2348-10-zhichao.gao@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Build-tested-by: Laszlo Ersek <lersek@redhat.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3003
There is a plan to make MD5 disable as default.
The new MACRO ENABLE_MD5_DEPRECATED_INTERFACES
would be introduced to enable MD5. Make the
definition ahead of the change to avoid build
error after the MACRO changed.
Enable iSCSI.
Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Message-Id: <20201112055558.2348-9-zhichao.gao@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Build-tested-by: Laszlo Ersek <lersek@redhat.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3003
There is a plan to make MD5 disable as default.
The new MACRO ENABLE_MD5_DEPRECATED_INTERFACES
would be introduced to enable MD5. Make the
definition ahead of the change to avoid build
error after the MACRO changed.
Enable iSCSI.
Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Message-Id: <20201112055558.2348-8-zhichao.gao@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Build-tested-by: Laszlo Ersek <lersek@redhat.com>
Consume the SEV-ES-independent reset vector restored in the previous
patch. Use the Null instance of VmgExitLib.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Message-Id: <20201112053153.22038-3-rebecca@bsdio.com>
Acked-by: Peter Grehan <grehan@freebsd.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Commits 6995a1b79b, 8a2732186a and 30937f2f98 modified all four
regular files under "OvmfPkg/ResetVector" with SEV-ES dependencies.
These are not relevant for Bhyve. Detach the pre-SEV-ES version of
ResetVector for Bhyve.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Message-Id: <20201112053153.22038-2-rebecca@bsdio.com>
Acked-by: Peter Grehan <grehan@freebsd.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3008
The QemuFlashPtrWrite() flash services runtime uses the GHCB and VmgExit()
directly to perform the flash write when running as an SEV-ES guest. If an
interrupt arrives between VmgInit() and VmgExit(), the Dr7 read in the
interrupt handler will generate a #VC, which can overwrite information in
the GHCB that QemuFlashPtrWrite() has set. This has been seen with the
timer interrupt firing and the CpuExceptionHandlerLib library code,
UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/
Xcode5ExceptionHandlerAsm.nasm and
ExceptionHandlerAsm.nasm
reading the Dr7 register while QemuFlashPtrWrite() is using the GHCB. In
general, it is necessary to protect the GHCB whenever it is used, not just
in QemuFlashPtrWrite().
Disable interrupts around the usage of the GHCB by modifying the VmgInit()
and VmgDone() interfaces:
- VmgInit() will take an extra parameter that is a pointer to a BOOLEAN
that will hold the interrupt state at the time of invocation. VmgInit()
will get and save this interrupt state before updating the GHCB.
- VmgDone() will take an extra parameter that is used to indicate whether
interrupts are to be (re)enabled. Before exiting, VmgDone() will enable
interrupts if that is requested.
Fixes: 437eb3f7a8
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Acked-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <c326a4fd78253f784b42eb317589176cf7d8592a.1604685192.git.thomas.lendacky@amd.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3008
The original SEV-ES support missed updating the QemuFlashEraseBlock()
function to successfully erase blocks. Update QemuFlashEraseBlock() to
call the QemuFlashPtrWrite() to be able to successfully perform the
commands under SEV-ES.
Fixes: 437eb3f7a8
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <309c5317a3107bd0e650be20731842a2e1d4b59a.1604685192.git.thomas.lendacky@amd.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3008
All fields that are set in the GHCB should have their associated bit in
the GHCB ValidBitmap field set. Add support to set the bit for the scratch
area field (SwScratch).
Fixes: 437eb3f7a8
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <cc8c8449740d2be0b287e6c69d48bf6cb067c7d8.1604685192.git.thomas.lendacky@amd.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3008
All fields that are set in the GHCB should have their associated bit in
the GHCB ValidBitmap field set. Add support to set the bit for the scratch
area field (SwScratch).
Fixes: c45f678a1e
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <45ccb63c2dadd834e2c47bf10c9e59c6766d7eb6.1604685192.git.thomas.lendacky@amd.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3008
All fields that are set in the GHCB should have their associated bit in
the GHCB ValidBitmap field set. Add support to set the bit for the scratch
area field (SwScratch).
Fixes: 0020157a98
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <f817d034cea37fa78e00e86f61c3445f1208226d.1604685192.git.thomas.lendacky@amd.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3008
All fields that are set in the GHCB should have their associated bit in
the GHCB ValidBitmap field set. Add support to set the bits for the
software exit information fields when performing a VMGEXIT (SwExitCode,
SwExitInfo1, SwExitInfo2).
Fixes: 61bacc0fa1
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <986e157c13bf33e529b1d16ab1b52e99a74a734f.1604685192.git.thomas.lendacky@amd.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3008
The VmgExitLib library added two new interfaces, VmgSetOffsetValid() and
VmgIsOffsetValid(), that must now be implemented in the OvmfPkg version
of the library.
Implement VmgSetOffsetValid() and VmgIsOffsetValid() and update existing
code, that is directly accessing ValidBitmap, to use the new interfaces.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <939e9dc375e6085bc67942fe9a00ecd4c6b77ecf.1604685192.git.thomas.lendacky@amd.com>
In QEMU commit range 4abf70a661a5..69699f3055a5 (later fixed up in QEMU
commit 4318432ccd3f), Phil implemented a QEMU facility for exposing the
host-side TLS cipher suite configuration to OVMF. The purpose is to
control the permitted ciphers in the guest's UEFI HTTPS boot. This
complements the forwarding of the host-side crypto policy from the host to
the guest -- the other facet was the set of CA certificates (for which
p11-kit patches had been upstreamed, on the host side).
Mention the new command line options in "OvmfPkg/README".
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Gary Lin <glin@suse.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2852
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Gary Lin <glin@suse.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20200922091827.12617-1-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Updates the DSC's for Ovmf based platforms to add a RngLib that uses the
TimerLib. This is due to a later change that adds TimerLib as a dependency
for OpenSSL. The TimerLib based RngLib mimics the behavior of OpenSSL
previously and it is recommended to switch to a better source of
entropy than the system's performance counter.
Ref: https://github.com/tianocore/edk2/pull/845
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1871
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Julien Grall <julien@xen.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Matthew Carlson <matthewfcarlson@gmail.com>
There is a DEBUG warning printout in VirtioMmioDeviceLib if the current
device's VendorID does not match the traditional 16-bit Red Hat PCIe
vendor ID used with virtio-pci. The virtio-mmio vendor ID is 32-bit and
has no connection to the PCIe registry.
Most specifically, this causes a bunch of noise when booting an AArch64
QEMU platform, since QEMU's virtio-mmio implementation used 'QEMU' as
the vendor ID:
VirtioMmioInit: Warning:
The VendorId (0x554D4551) does not match the VirtIo VendorId (0x1AF4).
Drop the warning message.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Signed-off-by: Leif Lindholm <leif@nuviainc.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
The "virsh setvcpus" (plural) command may hot-plug several VCPUs in quick
succession -- it means a series of "device_add" QEMU monitor commands,
back-to-back.
If a "device_add" occurs *just after* ACPI raises the broadcast SMI, then:
- the CPU_FOREACH() loop in QEMU's ich9_apm_ctrl_changed() cannot make the
SMI pending for the new CPU -- at that time, the new CPU doesn't even
exist yet,
- OVMF will find the new CPU however (in the CPU hotplug register block),
in QemuCpuhpCollectApicIds().
As a result, when the firmware sends an INIT-SIPI-SIPI to the new CPU in
SmbaseRelocate(), expecting it to boot into SMM (due to the pending SMI),
the new CPU instead boots straight into the post-RSM (normal mode) "pen",
skipping its initial SMI handler.
The CPU halts nicely in the pen, but its SMBASE is never relocated, and
the SMRAM message exchange with the BSP falls apart -- the BSP gets stuck
in the following loop:
//
// Wait until the hot-added CPU is just about to execute RSM.
//
while (Context->AboutToLeaveSmm == 0) {
CpuPause ();
}
because the new CPU's initial SMI handler never sets the flag to nonzero.
Fix this by sending a directed SMI to the new CPU just before sending it
the INIT-SIPI-SIPI. The various scenarios are documented in the code --
the cases affected by the patch are documented under point (2).
Note that this is not considered a security patch, as for a malicious
guest OS, the issue is not exploitable -- the symptom is a hang on the
BSP, in the above-noted loop in SmbaseRelocate(). Instead, the patch fixes
behavior for a benign guest OS.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Fixes: 51a6fb4118
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2929
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200826222129.25798-3-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
The "virsh setvcpus" (plural) command may hot-plug several VCPUs in quick
succession -- it means a series of "device_add" QEMU monitor commands,
back-to-back.
If a "device_add" occurs *just before* ACPI raises the broadcast SMI,
then:
- OVMF processes the hot-added CPU well.
- However, QEMU's post-SMI ACPI loop -- which clears the pending events
for the hot-added CPUs that were collected before raising the SMI -- is
unaware of the stray CPU. Thus, the pending event is not cleared for it.
As a result of the stuck event, at the next hot-plug, OVMF tries to re-add
(relocate for the 2nd time) the already-known CPU. At that time, the AP is
already in the normal edk2 SMM busy-wait however, so it doesn't respond to
the exchange that the BSP intends to do in SmbaseRelocate(). Thus the VM
gets stuck in SMM.
(Because of the above symptom, this is not considered a security patch; it
doesn't seem exploitable by a malicious guest OS.)
In CpuHotplugMmi(), skip the supposedly hot-added CPU if it's already
known. The post-SMI ACPI loop will clear the pending event for it this
time.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Fixes: bc498ac4ca
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2929
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200826222129.25798-2-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
OvmfPkg is the package, so while there are files to build bhyve
separately, they shouldn't have 'Pkg' in the name.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Peter Grehan <grehan@freebsd.org>
Message-Id: <20200818021035.6479-1-rebecca@bsdio.com>
Reviewed-by: Peter Grehan <grehan@freebsd.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
The ICH9_LPC_SMI_F_BROADCAST and ICH9_LPC_SMI_F_CPU_HOTPLUG feature flags
cause QEMU to behave as follows:
BROADCAST CPU_HOTPLUG use case / behavior
--------- ----------- ------------------------------------------------
clear clear OVMF built without SMM_REQUIRE; or very old OVMF
(from before commit a316d7ac91 / 2017-02-07).
QEMU permits CPU hotplug operations, and does
not cause the OS to inject an SMI upon hotplug.
Firmware is not expected to be aware of hotplug
events.
clear set Invalid feature set; QEMU rejects the feature
negotiation.
set clear OVMF after a316d7ac91 / 2017-02-07, built with
SMM_REQUIRE, but no support for CPU hotplug.
QEMU gracefully refuses hotplug operations.
set set OVMF after a316d7ac91 / 2017-02-07, built with
SMM_REQUIRE, and supporting CPU hotplug. QEMU
permits CPU hotplug operations, and causes the
OS to inject an SMI upon hotplug. Firmware is
expected to deal with hotplug events.
Negotiate ICH9_LPC_SMI_F_CPU_HOTPLUG -- but only if SEV is disabled, as
OvmfPkg/CpuHotplugSmm can't deal with SEV yet.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Liran Alon <liran.alon@oracle.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200714184305.9814-1-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Add configuration ExceptionList and IgnoreFiles for package config
files. So users can rely on this to ignore some Ecc issues.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
After having transitioned from UEFI to the OS, the OS will need to boot
the APs. For an SEV-ES guest, the APs will have been parked by UEFI using
GHCB pages allocated by UEFI. The hypervisor will write to the GHCB
SW_EXITINFO2 field of the GHCB when the AP is booted. As a result, the
GHCB pages must be marked reserved so that the OS does not attempt to use
them and experience memory corruption because of the hypervisor write.
Change the GHCB allocation from the default boot services memory to
reserved memory.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
A hypervisor is not allowed to update an SEV-ES guest's register state,
so when booting an SEV-ES guest AP, the hypervisor is not allowed to
set the RIP to the guest requested value. Instead an SEV-ES AP must be
re-directed from within the guest to the actual requested staring location
as specified in the INIT-SIPI-SIPI sequence.
Use the SEV-ES work area for the reset vector code that contains support
to jump to the desired RIP location after having been started. This is
required for only the very first AP reset.
This new OVMF source file, ResetVectorVtf0.asm, is used in place of the
original file through the use of the include path order set in
OvmfPkg/ResetVector/ResetVector.inf under "[BuildOptions]".
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
The flash detection routine will attempt to determine how the flash
device behaves (e.g. ROM, RAM, Flash). But when SEV-ES is enabled and
the flash device behaves as a ROM device (meaning it is marked read-only
by the hypervisor), this check may result in an infinite nested page fault
because of the attempted write. Since the instruction cannot be emulated
when SEV-ES is enabled, the RIP is never advanced, resulting in repeated
nested page faults.
When SEV-ES is enabled, exit the flash detection early and assume that
the FD behaves as Flash. This will result in QemuFlashWrite() being called
to store EFI variables, which will also result in an infinite nested page
fault when the write is performed. In this case, update QemuFlashWrite()
to use the VMGEXIT MMIO write support to have the hypervisor perform the
write without having to emulate the instruction.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Currently, the OVMF code relies on the hypervisor to enable the cache
support on the processor in order to improve the boot speed. However,
with SEV-ES, the hypervisor is not allowed to change the CR0 register
to enable caching.
Update the OVMF Sec support to enable caching in order to improve the
boot speed when running as an SEV-ES guest.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
An SEV-ES guest will generate a #VC exception when it encounters a
non-automatic exit (NAE) event. It is expected that the #VC exception
handler will communicate with the hypervisor using the GHCB to handle
the NAE event.
NAE events can occur during the Sec phase, so initialize exception
handling early in the OVMF Sec support.
Before establishing the exception handling, validate that the supported
version of the SEV-ES protocol in OVMF is supported by the hypervisor.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
During BSP startup, the reset vector code will issue a CPUID instruction
while in 32-bit mode. When running as an SEV-ES guest, this will trigger
a #VC exception.
Add exception handling support to the early reset vector code to catch
these exceptions. Also, since the guest is in 32-bit mode at this point,
writes to the GHCB will be encrypted and thus not able to be read by the
hypervisor, so use the GHCB CPUID request/response protocol to obtain the
requested CPUID function values and provide these to the guest.
The exception handling support is active during the SEV check and uses the
OVMF temporary RAM space for a stack. After the SEV check is complete, the
exception handling support is removed and the stack pointer cleared.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Protect the SEV-ES work area memory used by an SEV-ES guest.
Regarding the lifecycle of the SEV-ES memory area:
PcdSevEsWorkArea
(a) when and how it is initialized after first boot of the VM
If SEV-ES is enabled, the SEV-ES area is initialized during
the SEC phase [OvmfPkg/ResetVector/Ia32/PageTables64.asm].
(b) how it is protected from memory allocations during DXE
If SEV-ES is enabled, then InitializeRamRegions()
[OvmfPkg/PlatformPei/MemDetect.c] protects the ranges with either
an AcpiNVS (S3 enabled) or BootServicesData (S3 disabled) memory
allocation HOB, in PEI.
(c) how it is protected from the OS
If S3 is enabled, then (b) reserves it from the OS too.
If S3 is disabled, then the range needs no protection.
(d) how it is accessed on the S3 resume path
It is rewritten same as in (a), which is fine because (b) reserved it.
(e) how it is accessed on the warm reset path
It is rewritten same as in (a).
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Julien Grall <julien@xen.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Reserve a fixed area of memory for SEV-ES use and set a fixed PCD,
PcdSevEsWorkAreaBase, to this value.
This area will be used by SEV-ES support for two purposes:
1. Communicating the SEV-ES status during BSP boot to SEC:
Using a byte of memory from the page, the BSP reset vector code can
communicate the SEV-ES status to SEC for use before exception
handling can be enabled in SEC. After SEC, this field is no longer
valid and the standard way of determine if SEV-ES is active should
be used.
2. Establishing an area of memory for AP boot support:
A hypervisor is not allowed to update an SEV-ES guest's register
state, so when booting an SEV-ES guest AP, the hypervisor is not
allowed to set the RIP to the guest requested value. Instead an
SEV-ES AP must be re-directed from within the guest to the actual
requested staring location as specified in the INIT-SIPI-SIPI
sequence.
Use this memory for reset vector code that can be programmed to have
the AP jump to the desired RIP location after starting the AP. This
is required for only the very first AP reset.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
The SEV support will clear the C-bit from non-RAM areas. The early GDT
lives in a non-RAM area, so when an exception occurs (like a #VC) the GDT
will be read as un-encrypted even though it is encrypted. This will result
in a failure to be able to handle the exception.
Move the GDT into RAM so it can be accessed without error when running as
an SEV-ES guest.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Allocate memory for the GHCB pages and the per-CPU variable pages during
SEV initialization for use during Pei and Dxe phases. The GHCB page(s)
must be shared pages, so clear the encryption mask from the current page
table entries. Upon successful allocation, set the GHCB PCDs (PcdGhcbBase
and PcdGhcbSize).
The per-CPU variable page needs to be unique per AP. Using the page after
the GHCB ensures that it is unique per AP. Only the GHCB page is marked as
shared, keeping the per-CPU variable page encyrpted. The same logic is
used in DXE using CreateIdentityMappingPageTables() before switching to
the DXE pagetables.
The GHCB pages (one per vCPU) will be used by the PEI and DXE #VC
exception handlers. The #VC exception handler will fill in the necessary
fields of the GHCB and exit to the hypervisor using the VMGEXIT
instruction. The hypervisor then accesses the GHCB associated with the
vCPU in order to perform the requested function.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Protect the memory used by an SEV-ES guest when S3 is supported. This
includes the page table used to break down the 2MB page that contains
the GHCB so that it can be marked un-encrypted, as well as the GHCB
area.
Regarding the lifecycle of the GHCB-related memory areas:
PcdOvmfSecGhcbPageTableBase
PcdOvmfSecGhcbBase
(a) when and how it is initialized after first boot of the VM
If SEV-ES is enabled, the GHCB-related areas are initialized during
the SEC phase [OvmfPkg/ResetVector/Ia32/PageTables64.asm].
(b) how it is protected from memory allocations during DXE
If S3 and SEV-ES are enabled, then InitializeRamRegions()
[OvmfPkg/PlatformPei/MemDetect.c] protects the ranges with an AcpiNVS
memory allocation HOB, in PEI.
If S3 is disabled, then these ranges are not protected. DXE's own page
tables are first built while still in PEI (see HandOffToDxeCore()
[MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c]). Those tables are
located in permanent PEI memory. After CR3 is switched over to them
(which occurs before jumping to the DXE core entry point), we don't have
to preserve PcdOvmfSecGhcbPageTableBase. PEI switches to GHCB pages in
permanent PEI memory and DXE will use these PEI GHCB pages, so we don't
have to preserve PcdOvmfSecGhcbBase.
(c) how it is protected from the OS
If S3 is enabled, then (b) reserves it from the OS too.
If S3 is disabled, then the range needs no protection.
(d) how it is accessed on the S3 resume path
It is rewritten same as in (a), which is fine because (b) reserved it.
(e) how it is accessed on the warm reset path
It is rewritten same as in (a).
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Julien Grall <julien@xen.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
A GHCB page is needed during the Sec phase, so this new page must be
created. Since the #VC exception handler routines assume that a per-CPU
variable area is immediately after the GHCB, this per-CPU variable area
must also be created. Since the GHCB must be marked as an un-encrypted,
or shared, page, an additional pagetable page is required to break down
the 2MB region where the GHCB page lives into 4K pagetable entries.
Create a new entry in the OVMF memory layout for the new page table
page and for the SEC GHCB and per-CPU variable pages. After breaking down
the 2MB page, update the GHCB page table entry to remove the encryption
mask.
The GHCB page will be used by the SEC #VC exception handler. The #VC
exception handler will fill in the necessary fields of the GHCB and exit
to the hypervisor using the VMGEXIT instruction. The hypervisor then
accesses the GHCB in order to perform the requested function.
Four new fixed PCDs are needed to support the SEC GHCB page:
- PcdOvmfSecGhcbBase UINT32 value that is the base address of the
GHCB used during the SEC phase.
- PcdOvmfSecGhcbSize UINT32 value that is the size, in bytes, of the
GHCB area used during the SEC phase.
- PcdOvmfSecGhcbPageTableBase UINT32 value that is address of a page
table page used to break down the 2MB page into
512 4K pages.
- PcdOvmfSecGhcbPageTableSize UINT32 value that is the size, in bytes,
of the page table page.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
When SEV-ES is enabled, then SEV is also enabled. Add support to the SEV
initialization function to also check for SEV-ES being enabled, and if
enabled, set the SEV-ES enabled PCD (PcdSevEsIsEnabled).
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Create a function that can be used to determine if the VM is running
as an SEV-ES guest.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Under SEV-ES, a DR7 read or write intercept generates a #VC exception.
The #VC handler must provide special support to the guest for this. On
a DR7 write, the #VC handler must cache the value and issue a VMGEXIT
to notify the hypervisor of the write. However, the #VC handler must
not actually set the value of the DR7 register. On a DR7 read, the #VC
handler must return the cached value of the DR7 register to the guest.
VMGEXIT is not invoked for a DR7 register read.
The caching of the DR7 values will make use of the per-CPU data pages
that are allocated along with the GHCB pages. The per-CPU page for a
vCPU is the page that immediately follows the vCPU's GHCB page. Since
each GHCB page is unique for a vCPU, the page that follows becomes
unique for that vCPU. The SEC phase will reserves an area of memory for
a single GHCB and per-CPU page for use by the BSP. After transitioning
to the PEI phase, new GHCB and per-CPU pages are allocated for the BSP
and all APs.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Under SEV-ES, a MWAIT/MWAITX intercept generates a #VC exception.
VMGEXIT must be used to allow the hypervisor to handle this intercept.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Under SEV-ES, a MONITOR/MONITORX intercept generates a #VC exception.
VMGEXIT must be used to allow the hypervisor to handle this intercept.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Under SEV-ES, a RDTSCP intercept generates a #VC exception. VMGEXIT must be
used to allow the hypervisor to handle this intercept.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Under SEV-ES, a VMMCALL intercept generates a #VC exception. VMGEXIT must
be used to allow the hypervisor to handle this intercept.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Under SEV-ES, a INVD intercept generates a #VC exception. VMGEXIT must be
used to allow the hypervisor to handle this intercept.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Under SEV-ES, a RDPMC intercept generates a #VC exception. VMGEXIT must be
used to allow the hypervisor to handle this intercept.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Under SEV-ES, a RDTSC intercept generates a #VC exception. VMGEXIT must be
used to allow the hypervisor to handle this intercept.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Under SEV-ES, a WBINVD intercept generates a #VC exception. VMGEXIT must be
used to allow the hypervisor to handle this intercept.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Under SEV-ES, a NPF intercept for an NPT entry with a reserved bit set
generates a #VC exception. This condition is assumed to be an MMIO access.
VMGEXIT must be used to allow the hypervisor to handle this intercept.
Add support to construct the required GHCB values to support a NPF NAE
event for MMIO. Parse the instruction that generated the #VC exception,
setting the required register values in the GHCB and creating the proper
SW_EXIT_INFO1, SW_EXITINFO2 and SW_SCRATCH values in the GHCB.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Under SEV-ES, a MSR_PROT intercept generates a #VC exception. VMGEXIT must
be used to allow the hypervisor to handle this intercept.
Add support to construct the required GHCB values to support an MSR_PROT
NAE event. Parse the instruction that generated the #VC exception to
determine whether it is RDMSR or WRMSR, setting the required register
register values in the GHCB and creating the proper SW_EXIT_INFO1 value in
the GHCB.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Under SEV-ES, a CPUID intercept generates a #VC exception. VMGEXIT must be
used to allow the hypervisor to handle this intercept.
Add support to construct the required GHCB values to support a CPUID NAE
event. Additionally, CPUID 0x0000_000d (CPUID_EXTENDED_STATE) requires
XCR0 to be supplied in the GHCB, so add support to issue the XGETBV
instruction.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Add support to the #VC exception handler to handle string IO. This
requires expanding the IO instruction parsing to recognize string based
IO instructions as well as preparing an un-encrypted buffer to be used
to transfer (either to or from the guest) the string contents for the IO
operation. The SW_EXITINFO2 and SW_SCRATCH fields of the GHCB are set
appropriately for the operation. Multiple VMGEXIT invocations may be
needed to complete the string IO operation.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Under SEV-ES, a IOIO_PROT intercept generates a #VC exception. VMGEXIT
must be used to allow the hypervisor to handle this intercept.
Add support to construct the required GHCB values to support a IOIO_PROT
NAE event. Parse the instruction that generated the #VC exception,
setting the required register values in the GHCB and creating the proper
SW_EXITINFO1 value in the GHCB.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
The base VmgExitLib library provides a default limited interface. As it
does not provide full support, create an OVMF version of this library to
begin the process of providing full support of SEV-ES within OVMF.
SEV-ES support is only provided for X64 builds, so only OvmfPkgX64.dsc is
updated to make use of the OvmfPkg version of the library.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
Various CpuExceptionHandlerLib libraries will updated to use the new
VmgExitLib library. To prevent any build breakage, update the OvmfPkg
DSC files that use a form of the CpuExceptionHandlerLib library to
include the VmgExitLib library.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Julien Grall <julien@xen.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
Sean reports that having two DEC files under OvmfPkg violates the DEC
spec:
> An EDK II Package (directory) is a directory that contains an EDK II
> package declaration (DEC) file. Only one DEC file is permitted per
> directory. EDK II Packages cannot be nested within other EDK II
> Packages.
This issue originates from commit 656419f922 ("Add BhyvePkg, to support
the bhyve hypervisor", 2020-07-31).
Remedy the problem as follows. (Note that these steps are not split to
multiple patches in order to keep Bhyve buildable across the transition.)
(1) Delete "OvmfPkg/Bhyve/BhyvePkg.dec".
(2) Point the [Packages] sections of the Bhyve-specific AcpiPlatformDxe,
BhyveRfbDxe, and BhyveFwCtlLib INF files to "OvmfPkg.dec".
(3) Migrate the artifacts that "BhyvePkg.dec" used to have on top of
"OvmfPkg.dec" as follows:
(3a) Merge the copyright notices from Rebecca Cran and Pluribus Networks
into "OvmfPkg.dec".
(3b) Merge the "BhyveFwCtlLib" class header definition into "OvmfPkg.dec".
(3c) Merge value 0x2F8 for the fixed PcdDebugIoPort into
"BhyvePkgX64.dsc".
(4) Unnest the the Include/Library/ and Library/ subtrees from under
OvmfPkg/Bhyve to the corresponding, preexistent subtrees in OvmfPkg.
The goal is to keep the [Includes] section in the "OvmfPkg.dec" file
unchanged, plus simplify references in "BhyvePkgX64.dsc". Non-library
modules remain under "OvmfPkg/Bhyve/".
(4a) The BhyveFwCtlLib class header, and sole instance, are already
uniquely named, so their movements need not involve file renames.
(4b) Rename the Bhyve-specific PlatformBootManagerLib instance to
PlatformBootManagerLibBhyve, in additon to moving it, for
distinguishing it from OvmfPkg's preexistent lib instance. Apply the
name change to all three of the lib instance directory name, the INF
file, and the BASE_NAME define in the INF file.
(4c) Update lib class resolutions in "BhyvePkgX64.dsc" accordingly.
(5) Replace the "ACPI table storage" FILE_GUID in
"OvmfPkg/Bhyve/AcpiTables/AcpiTables.inf" with a new GUID, and
open-code the "ACPI table storage" GUID in the "ACPITABLE" FDF rule
instead, replacing $(NAMED_GUID). This step is necessary because CI
requires unique FILE_GUIDs over all INF files, and OVMF's original
"AcpiTables.inf" already uses the "ACPI table storage" GUID as
FILE_GUID.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Rebecca Cran <rebecca@bsdio.com>
Cc: Sean Brogan <spbrogan@outlook.com>
Fixes: 656419f922
Reported-by: Sean Brogan <spbrogan@outlook.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200801155024.16439-1-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
BhyvePkg supports the bhyve hypervisor, which is a hypervisor/virtual
machine manager available on FreeBSD, macOS and Illumos.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Message-Id: <20200713054131.479627-2-rebecca@bsdio.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Add configuration IgnoreFiles for package config files.
So users can rely on this to skip license conflict for
some generated files.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
This is the second part of LsiScsiPassThru(). LsiScsiProcessRequest() is
added to translate the SCSI Request Packet into the LSI 53C895A
commands. This function utilizes the so-called Script buffer to transmit
a series of commands to the chip and then polls the DMA Status (DSTAT)
register until the Scripts Interrupt Instruction Received (SIR) bit
sets. Once the script is done, the SCSI Request Packet will be modified
to reflect the result of the script. The Cumulative SCSI Byte Count
(CSBC) register is fetched before and after the script to calculate the
transferred bytes and update InTransferLength/OutTransferLength if
necessary.
v3:
- Set DStat, SIst0, and SIst1 to 0 before using them
- Amend the if statements for the DMA data instruction and add the
assertions for the data direction
- Also set SenseDataLength to 0 on the error path
- Fix typos and amend comments
- Amend the error handling of the calculation of transferred bytes
v2:
- Use the BITx macros for the most of LSI_* constants
- Fix a typo: contorller => controller
- Add SeaBIOS lsi-scsi driver as one of the references of the script
- Cast the result of sizeof to UINT32 for the instructions of the
script
- Drop the backslashes
- Replace LSI_SCSI_DMA_ADDR_LOW with LSI_SCSI_DMA_ADDR since we
already removed DUAL_ADDRESS_CYCLE
- Add more comments for the script
- Fix the check of the script size at the end of the script
- Always set SenseDataLength to 0 to avoid the caller to access
SenseData
- Improve the error handling in LsiScsiProcessRequest()
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Signed-off-by: Gary Lin <glin@suse.com>
Message-Id: <20200717061130.8881-11-glin@suse.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
This is the first part of LsiScsiPassThru(). Before processing the SCSI
Request packet, we have to make sure whether the packet is valid or not.
v2: Make LsiScsiPassThru() return EFI_UNSUPPORTED since this function is
half-implemented
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200717061130.8881-10-glin@suse.com>
Map DMA buffer and perpare for the implementation of LsiScsiPassThru().
v2:
- Replace 0x10000 with SIZE_64KB macro for the DMA buffer data array
- Remove DUAL_ADDRESS_CYCLE from PciIo since we don't really need
64-bit DMA address
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200717061130.8881-9-glin@suse.com>
Open PciIo protocol and use it to initialize the device. The
initialization of LSI 53C895A is simple: just set the SRST bit in
Interrupt Status Zero register to reset the device.
v2:
- Use the BITx macros for the bit constants
- Add the closing of PciIo protocol in LsiScsiControllerStop()
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Signed-off-by: Gary Lin <glin@suse.com>
Message-Id: <20200717061130.8881-8-glin@suse.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Implement LsiScsiGetNextTargetLun(), LsiScsiBuildDevicePath(),
LsiScsiGetTargetLun(), and LsiScsiGetNextTarget() to report Targets and
LUNs and build the device path.
This commit also introduces two PCD value: PcdLsiScsiMaxTargetLimit and
PcdLsiScsiMaxLunLimit as the limits for Targets and LUNs.
v3:
- Update the range of LUN in the assertioin
- Squash the spurious newline into the previous commit
v2:
- Zero out (*Target) in LsiScsiGetTargetLun()
- Use CopyMem() instead of the one-byte shortcut to copy target from
ScsiDevicePath->Pun
- Add asserts for PcdLsiScsiMaxTargetLimit and PcdLsiScsiMaxLunLimit
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Signed-off-by: Gary Lin <glin@suse.com>
Message-Id: <20200717061130.8881-7-glin@suse.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Partially implement LsiScsiControllerStart() and LsiScsiControllerStop()
to insert the scaffolding of EXT_SCSI_PASS_THRU functions.
v3: Squash the newline below the declaration of LSI_SCSI_FROM_PASS_THRU
v2: Remove the closing of PciIo protocol from LsiScsiControllerStop().
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200717061130.8881-6-glin@suse.com>
Implement LsiScsiControllerSupported() to probe the PCI ID and look for
LSI 53C895A.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200717061130.8881-5-glin@suse.com>
Implement LsiScsiGetDriverName() and LsiScsiGetDeviceName()
to report the name of the driver.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200717061130.8881-4-glin@suse.com>
Create the driver with only a dummy LsiScsiEntryPoint() for the further
implementation of the driver for LSI 53C895A SCSI controller.
v2: Fix the mixed-case GUID string
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200717061130.8881-2-glin@suse.com>
The token value of PcdMptScsiStallPerPollUsec should be 0x3a since the
previous token value is 0x39.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Liran Alon <liran.alon@oracle.com>
Cc: Nikita Leshenko <nikita.leshchenko@oracle.com>
Signed-off-by: Gary Lin <glin@suse.com>
Message-Id: <20200715082031.30978-1-glin@suse.com>
Reviewed-by: Liran Alon <liran.alon@oracle.com>
[lersek@redhat.com: clarify subject, fix typos in commit message]
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
RestoreTPL called while at TPL_HIGH_LEVEL unconditionally enables
interrupts even if called in interrupt handler. That opens a window while
interrupt is not completely handled but another interrupt could be
accepted.
If a VM starts on a heavily loaded host hundreds of periodic timer
interrupts might be queued while vCPU is descheduled (the behavior is
typical for a Xen host). The next time vCPU is scheduled again all of them
get delivered back to back causing OVMF to accept each one without
finishing a previous one and cleaning up the stack. That quickly results
in stack overflow and a triple fault.
Fix it by postponing sending EOI until we finished processing the current
tick giving interrupt handler opportunity to clean up the stack before
accepting the next tick.
Signed-off-by: Igor Druzhinin <igor.druzhinin@citrix.com>
Message-Id: <1592275782-9369-1-git-send-email-igor.druzhinin@citrix.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2815
Acked-by: Laszlo Ersek <lersek@redhat.com>
[lersek@redhat.com: add BZ ref; rewrap msg to silence PatchCheck.py]
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2786
Since the type of PcdStatusCodeUseSerial and PcdStatusCodeUseMemory
in MdeModulePkg.dec are changed, so change them from
PcdsFeatureFlag to PcdsFixedAtBuild in dsc files.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Signed-off-by: Ming Tan <ming.tan@intel.com>
This reverts commit ced77332ca.
The command
virt-install --location NETWORK-URL
downloads the vmlinuz and initrd files from the remote OS tree, and passes
them to the guest firmware via fw_cfg.
When used with IA32 / X64 guests, virt-install expects the guest firmware
to do two things, at the same time:
- launch the fw_cfg kernel image even if the latter does not pass SB
verification (SB checking is supposed to be bypassed entirely in favor
of the Linux/x86 Boot Protocol),
- still let the guest kernel perceive SB as enabled.
Commit ced77332ca prevented this, by removing the Linux/x86 Boot
Protocol from such an OVMF image that was built with SECURE_BOOT_ENALBE.
While that's the right thing in theory, in practice "virt-install
--location NETWORK-URL" is entrenched, and we shouldn't break it.
We can tolerate the Linux/x86 Boot Protocol as a one-of-a-kind SB bypass
for direct-booted kernels, because:
- the fw_cfg content comes from QEMU, and the guest is already at QEMU's
mercy,
- in the guest, OS boots after the initial installation will use "shim"
rather than an fw_cfg kernel, which we can consider somewhat similar to
"Audit Mode / Deployed Mode" (~ trust for install, lock down after).
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Message-Id: <20200615144514.24597-1-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
[lersek@redhat.com: truncate the subject line, originally auto-generated
by git-revert, to pacify PatchCheck.py]
gBS->LoadImage() returning EFI_NOT_FOUND is an expected condition; it
means that QEMU wasn't started with "-kernel". Log this status code as
INFO rather than ERROR.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200609105414.12474-1-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
When an image fails Secure Boot validation, LoadImage() returns
EFI_SECURITY_VIOLATION if the platform policy is
DEFER_EXECUTE_ON_SECURITY_VIOLATION.
If the platform policy is DENY_EXECUTE_ON_SECURITY_VIOLATION, then
LoadImage() returns EFI_ACCESS_DENIED (and the image does not remain
loaded).
(Before <https://bugzilla.tianocore.org/show_bug.cgi?id=2129>, this
difference would be masked, as DxeImageVerificationLib would incorrectly
return EFI_SECURITY_VIOLATION for DENY_EXECUTE_ON_SECURITY_VIOLATION as
well.)
In X86QemuLoadImageLib, proceed to the legacy Linux/x86 Boot Protocol upon
seeing EFI_ACCESS_DENIED too.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2785
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200605235242.32442-1-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
BaseLib interfaces (namely, SwapBytesXx()) are only used in
"Tpm12Support.c", which is IA32/X64-only. Therefore the BaseLib class
dependency should also be restricted to IA32 & X64, in the INF file.
The "#include <Library/BaseLib.h>" directive is already present in
"Tpm12Support.c" only.
(The BaseLib dependency should have been restricted to IA32 and X64
together with the Tpm12DeviceLib dependency, as part of commit
74f90d38c4, "OvmfPkg/Tcg2ConfigPei: skip TPM-1.2 detection when building
for ARM/AARCH64", 2020-05-21.)
This is a trivial cleanup; functionally a no-op.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Stefan Berger <stefanb@linux.ibm.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2752
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200603170413.23936-3-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
The leading comments in "Tcg2ConfigPei.inf" and "Tcg2ConfigPeim.c" say,
"In OvmfPkg, the module only performs TPM2 hardware detection".
The statement hasn't been correct since commit 8923699291 ("OvmfPkg:
detect TPM 1.2 in Tcg2ConfigPei", 2020-03-04). Replace "TPM2" with "TPM"
(without stating a version) in those file-top comments.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Stefan Berger <stefanb@linux.ibm.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2752
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200603170413.23936-2-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Dating back to commits f5cb376703 and ddd34a8183, the
"ArmVirtPkg/ArmVirtQemu.dsc" platform includes the
"OvmfPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf" module when the TPM2_ENABLE
build flag is defined.
This was regressed in commit 8923699291, which added a Tpm12DeviceLib
dependency to Tcg2ConfigPei. "ArmVirtQemu.dsc" does not resolve that class
to any instance, so now we get a build failure:
> build.py...
> ArmVirtPkg/ArmVirtQemu.dsc(...): error 4000: Instance of library class
> [Tpm12DeviceLib] is not found
> in [OvmfPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf] [AARCH64]
> consumed by module [OvmfPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf]
The TPM-1.2 code in OvmfPkg/Tcg2ConfigPei is limited to a special use case
(a kind of physical TPM-1.2 assignment), and that has never applied to
"ArmVirtQemu.dsc".
Short-circuit the TPM-1.2 detection in the ARM/AARCH64 builds of
OvmfPkg/Tcg2ConfigPei, removing the Tpm12DeviceLib dependency.
Functionally, this patch is a no-op on IA32 / X64.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Eric Auger <eric.auger@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Simon Hardy <simon.hardy@itdev.co.uk>
Cc: Stefan Berger <stefanb@linux.ibm.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2728
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200520225841.17793-4-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Move the calls to the Tpm12RequestUseTpm() and Tpm12SubmitCommand()
Tpm12DeviceLib functions to a separate C file, so that we can override
these actions in a subsequent patch.
This code movement requires moving the TPM_RSP_GET_TICKS / TestTpm12()
helper structure / function too.
While at it, give the TestTpm12() function @retval / @return
documentation, plus wrap an overlong line in it.
Functionally, this patch is a no-op.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Eric Auger <eric.auger@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Simon Hardy <simon.hardy@itdev.co.uk>
Cc: Stefan Berger <stefanb@linux.ibm.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2728
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200520225841.17793-3-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Commit 8923699291 introduced an explicit Tpm12CommandLib dependency to
Tcg2ConfigPei.
In reality this lib class is not consumed by Tcg2ConfigPei at all (such a
dependency is not even inherited from other lib instances). Simplify the
module by dropping the superfluous dependency.
(The Tpm12CommandLib class resolution that was also added in commit
8923699291 is not useless, at the platform build level: it is consumed
by TcgPei and TcgDxe. Meaning that said Tpm12CommandLib resolution should
have likely been a part of the subsequent patch in the original series,
namely commit 6be54f15a0c9.)
Commit 8923699291 also introduced SwapBytesXx() calls. Those functions
are provided by BaseLib. Spell out the BaseLib dependency.
Functionally, this patch is a no-op.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Eric Auger <eric.auger@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Simon Hardy <simon.hardy@itdev.co.uk>
Cc: Stefan Berger <stefanb@linux.ibm.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2728
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200520225841.17793-2-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Any new OVMF binary (containing commit d42fdd6f83, and built with
SMM_REQUIRE) is likely to reboot during its first boot, regardless of
whether the variable store is logically empty, or it contains a
MemoryTypeInformation variable from an earlier OVMF binary.
This "reboot on first boot after OVMF upgrade" occurs despite having
eliminated BS Code/Data tracking in earlier parts of this series. Meaning
that we've outgrown the bins of those memory types too that matter for SMM
security.
Eliminating said reboot will make an upgrade to edk2-stable202005 more
comfortable for users. Increase the defaults empirically. (The total
doesn't exceed 3MB by much.)
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2706
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200508121651.16045-5-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Some OvmfPkg modules already depend on "EmbeddedPkg.dec"; thus, replace
the open-coded memory type info defaults in the source code with the
EmbeddedPkg PCDs that stand for the same purpose. Consequently, platform
builders can override these values with the "--pcd" option of "build",
without source code updates.
While at it, sort the memory type names alphabetically.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2706
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200508121651.16045-4-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
The previous patch has no effect -- i.e., it cannot stop the tracking of
BS Code/Data in MemTypeInfo -- if the virtual machine already has a
MemoryTypeInformation UEFI variable.
In that case, our current logic allows the DXE IPL PEIM to translate the
UEFI variable to the HOB, and that translation is verbatim. If the
variable already contains records for BS Code/Data, the issues listed in
the previous patch persist for the virtual machine.
For this reason, *always* install PlatformPei's own MemTypeInfo HOB. This
prevents the DXE IPL PEIM's variable-to-HOB translation.
In PlatformPei, consume the records in the MemoryTypeInformation UEFI
variable as hints:
- Ignore all memory types for which we wouldn't by default install records
in the HOB. This hides BS Code/Data from any existent
MemoryTypeInformation variable.
- For the memory types that our defaults cover, enable the records in the
UEFI variable to increase (and *only* to increase) the page counts.
This lets the MemoryTypeInformation UEFI variable function as designed,
but it eliminates a reboot when such a new OVMF binary is deployed (a)
that has higher memory consumption than tracked by the virtual machine's
UEFI variable previously, *but* (b) whose defaults also reflect those
higher page counts.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2706
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200508121651.16045-3-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
In commit d42fdd6f83 ("OvmfPkg: improve SMM comms security with adaptive
MemoryTypeInformation", 2020-03-12), we enabled the boot-to-boot tracking
of the usages of various UEFI memory types.
Both whitepapers listed in that commit recommend that BS Code/Data type
memory *not* be tracked. This recommendation was confirmed by Jiewen in
the following two messages as well:
[1] https://edk2.groups.io/g/devel/message/55741http://mid.mail-archive.com/74D8A39837DF1E4DA445A8C0B3885C503F97B579@shsmsx102.ccr.corp.intel.com
[2] https://edk2.groups.io/g/devel/message/55749http://mid.mail-archive.com/74D8A39837DF1E4DA445A8C0B3885C503F97BDC5@shsmsx102.ccr.corp.intel.com
While tracking BS Code/Data type memory has one benefit (it de-fragments
the UEFI memory map), the downsides outweigh it. Spikes in BS Data type
memory usage are not uncommon in particular, and they may have the
following consequences:
- such reboots during normal boot that look "spurious" to the end user,
and have no SMM security benefit,
- a large BS Data record in MemoryTypeInformation may cause issues when
the DXE Core tries to prime the according bin(s), but the system's RAM
size has been reduced meanwhile.
Removing the BS Code/Data entries from MemoryTypeInformation leads to a
bit more fragmentation in the UEFI memory map, but that should be
harmless.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2706
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200508121651.16045-2-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
OVMF booting stops with the assert if built with Xcode on macOS:
Loading driver at 0x0001FAB8000 EntryPoint=0x0001FABF249 LinuxInitrdDynamicShellCommand.efi
InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 1F218398
ProtectUefiImageCommon - 0x1F218140
- 0x000000001FAB8000 - 0x0000000000008A60
ASSERT_EFI_ERROR (Status = Unsupported)
ASSERT LinuxInitrdDynamicShellCommand.c(378): !EFI_ERROR (Status)
The assert comes from InitializeHiiPackage() after an attempt to
retrieve HII package list from ImageHandle.
Xcode still doesn't support HII resource section and
LinuxInitrdDynamicShellCommand depends on it. Likewise 277a3958d9
("OvmfPkg: Don't include TftpDynamicCommand in XCODE5 tool chain"),
disable initrd command if built with Xcode toolchain
Fixes: ec41733cfd ("OvmfPkg: add the 'initrd' dynamic shell command")
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Andrew Fish <afish@apple.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
Message-Id: <20200514134820.62047-1-r.bolshakov@yadro.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2340
During the SEC phase, use the XCODE5 CpuExceptionHandlerLib library in
place of the standard library when building with the XCODE5 toolchain.
The SEC XCODE5 version of the library performs binary patching and should
only be used when building with the XCODE5 toolchain.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Julien Grall <julien@xen.org>
Cc: Liming Gao <liming.gao@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <0cfdd51deb6d39e08380645f2022b9b76e29f66f.1588856809.git.thomas.lendacky@amd.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
This causes the device to forget about the reply frame. We allocated the
reply frame in EfiBootServicesData type memory, and code executing after
ExitBootServices() is permitted to overwrite it.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390
Signed-off-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200504210607.144434-13-nikita.leshchenko@oracle.com>
Machines should be able to boot after this commit. Tested with different
Linux distributions (Ubuntu, CentOS) and different Windows
versions (Windows 7, Windows 10, Server 2016).
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390
Signed-off-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200504210607.144434-12-nikita.leshchenko@oracle.com>
[lersek@redhat.com: MPT_SCSI_DMA_ADDR_HIGH: drop redundant space char]
Reset and send the IO controller initialization request. The reply is
read back to complete the doorbell function but it isn't useful to us
because it doesn't contain relevant data or status codes.
See "LSI53C1030 PCI-X to Dual Channel Ultra320 SCSI Multifunction
Controller" technical manual for more information.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390
Signed-off-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
Message-Id: <20200504210607.144434-11-nikita.leshchenko@oracle.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Enable the IO Space and Bus Mastering and restore the original values
when the device is stopped. This is a standard procedure in PCI
drivers.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390
Signed-off-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
Reviewed-by: Liran Alon <liran.alon@oracle.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200504210607.144434-10-nikita.leshchenko@oracle.com>
This will give us an exclusive access to the PciIo of this device
after it was started and until is will be stopped.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390
Signed-off-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
Reviewed-by: Liran Alon <liran.alon@oracle.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200504210607.144434-9-nikita.leshchenko@oracle.com>
The controller supports up to 8 targets in practice (Not reported by the
controller, but based on the implementation of the virtual device),
report them in GetNextTarget and GetNextTargetLun. The firmware will
then try to communicate with them and create a block device for each one
that responds.
Support for multiple LUNs will be implemented in another series.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390
Signed-off-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200504210607.144434-7-nikita.leshchenko@oracle.com>
Support dynamic insertion and removal of the protocol
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390
Signed-off-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200504210607.144434-6-nikita.leshchenko@oracle.com>
The MptScsiControllerSupported function is called on handles passed in
by the ConnectController() boot service and if the handle is the
lsi53c1030 controller the function would return success. A successful
return value will attach our driver to the device.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390
Signed-off-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liran Alon <liran.alon@oracle.com>
Message-Id: <20200504210607.144434-5-nikita.leshchenko@oracle.com>
Install Component Name protocols to have a nice display name for the
driver in places such as UEFI shell.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390
Signed-off-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Liran Alon <liran.alon@oracle.com>
Message-Id: <20200504210607.144434-4-nikita.leshchenko@oracle.com>
In order to probe and connect to the MptScsi device we need this
protocol. Currently it does nothing.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390
Signed-off-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liran Alon <liran.alon@oracle.com>
Message-Id: <20200504210607.144434-3-nikita.leshchenko@oracle.com>
Ankur Arora
Kun Qin
Tom Lendacky
Laszlo Ersek
Jiahui Cen via groups.io
Igor Druzhinin
Leif Lindholm
Michael D Kinney
Borghorst, Hendrik via groups.io
James Bottomley
Sean Brogan
Rebecca Cran
Wenyi Xie
Gao, Zhichao
Bret Barkelew
Vladimir Olovyannikov
Matthew Carlson
Shenglei Zhang
Gary Lin
Tan, Ming
Roman Bolshakov
Nikita Leshenko