summaryrefslogtreecommitdiffstats
path: root/OvmfPkg
Commit message (Collapse)AuthorAgeFilesLines
* OvmfPkg/QemuFlashFvbServicesRuntimeDxe: Use physical address with SEV-ESTom Lendacky2021-01-261-1/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: 437eb3f7a8db7681afe0e6064d3a8edb12abb766 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>
* OvmfPkg/CpuS3DataDxe: do not allocate useless register tablesLaszlo Ersek2021-01-202-70/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 e992cc3f4859 ("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 1158fc8e2c7b ("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>
* OvmfPkg/PciHostBridgeUtilityLib: Extend GetRootBridges() with BusMin/BusMaxJiahui Cen via groups.io2021-01-203-5/+32
| | | | | | | | | | | | | | | | | | 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/PciHostBridgeUtilityLib: Extend parameter list of GetRootBridgesJiahui Cen via groups.io2021-01-204-28/+39
| | | | | | | | | | | | | | | Extend parameter list of PciHostBridgeUtilityGetRootBridges() with DmaAbove4G, NoExtendedConfigSpace to support for ArmVirtPkg. 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> Signed-off-by: Yubo Miao <miaoyubo@huawei.com> Message-Id: <20210119011302.10908-9-cenjiahui@huawei.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/PciHostBridgeLib: Extract GetRootBridges() / FreeRootBridges()Jiahui Cen via groups.io2021-01-205-135/+256
| | | | | | | | | | | | | | | | | | | Extract PciHostBridgeGetRootBridges() / PciHostBridgeFreeRootBridges() to PciHostBridgeUtilityLib as common utility functions to share support for scanning extra root bridges. No change of functionality. 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> Signed-off-by: Yubo Miao <miaoyubo@huawei.com> Message-Id: <20210119011302.10908-8-cenjiahui@huawei.com> [lersek@redhat.com: keep zeroing of (*Count) centralized] Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/PciHostBridgeUtilityLib: Extend parameters of InitRootBridge()Jiahui Cen via groups.io2021-01-206-57/+73
| | | | | | | | | | | | | | | | | | Extend parameter list of PciHostBridgeUtilityInitRootBridge() with DmaAbove4G and NoExtendedConfigSpace to prepare for sharing with ArmVirtPkg. 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> Signed-off-by: Yubo Miao <miaoyubo@huawei.com> Message-Id: <20210119011302.10908-6-cenjiahui@huawei.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/PciHostBridgeLib: Extract InitRootBridge() / UninitRootBridge()Jiahui Cen via groups.io2021-01-207-213/+249
| | | | | | | | | | | | | | | | | Extract InitRootBridge() / UninitRootBridge() to PciHostBridgeUtilityLib as common utility functions. No change of functionality. 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> Signed-off-by: Yubo Miao <miaoyubo@huawei.com> Message-Id: <20210119011302.10908-5-cenjiahui@huawei.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/PciHostBridgeLib: List missing PcdLib dependencyJiahui Cen via groups.io2021-01-203-0/+3
| | | | | | | | | | | | | | | | | 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>
* OvmfPkg: Introduce PciHostBridgeUtilityLib classJiahui Cen via groups.io2021-01-2012-39/+166
| | | | | | | | | | | | | | | | | | | | | | Introduce a new PciHostBridgeUtilityLib class to share duplicate code between OvmfPkg and ArmVirtPkg. Extract function PciHostBridgeUtilityResourceConflict from PciHostBridgeResourceConflict in OvmfPkg/PciHostBridgeLib. 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: Rebecca Cran <rebecca@bsdio.com> Cc: Peter Grehan <grehan@freebsd.org> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien@xen.org> Signed-off-by: Jiahui Cen <cenjiahui@huawei.com> Signed-off-by: Yubo Miao <miaoyubo@huawei.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20210119011302.10908-2-cenjiahui@huawei.com>
* OvmfPkg: disable list length checks in NOOPT and DEBUG buildsLaszlo Ersek2021-01-196-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* OvmfPkg: raise PcdShellFileOperationSize to 128KBLaszlo Ersek2021-01-193-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* OvmfPkg/XenPlatformPei: Use CPUID to get physical address width on XenIgor Druzhinin2021-01-192-154/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]
* OvmfPkg: add TimeBaseLib resolution for OvmfXenLeif Lindholm2021-01-081-0/+1
| | | | | | | | | | | | | | | | Commit 55ee36b0c490 ("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>
* OvfmPkg/VmgExitLib: Validate #VC MMIO is to un-encrypted memoryTom Lendacky2021-01-076-1/+88
| | | | | | | | | | | | | | | | | | | | | | | 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>
* OvmfPkg/PlatformPei: Reserve GHCB backup pages if S3 is supportedTom Lendacky2021-01-072-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* OvmfPkg/VmgExitLib: Support nested #VCsTom Lendacky2021-01-0713-27/+404
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* OvmfPkg/MemEncryptSevLib: Address range encryption state interfaceTom Lendacky2021-01-0710-12/+368
| | | | | | | | | | | | | | | | | 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>
* OvmfPkg/MemEncryptSevLib: Make the MemEncryptSevLib available for SECTom Lendacky2021-01-077-4/+289
| | | | | | | | | | | | | | | | | | | | | | 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>
* OvmfPkg/MemEncryptSevLib: Coding style fixes in prep for SEC libraryTom Lendacky2021-01-071-6/+6
| | | | | | | | | | | | | | | | 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>
* OvmfPkg/VmgExitLib: Check for an explicit DR7 cached valueTom Lendacky2021-01-071-4/+7
| | | | | | | | | | | | | | | | 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>
* OvmfPkg/AmdSevDxe: Clear encryption bit on PCIe MMCONFIG rangeTom Lendacky2021-01-072-2/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* OvmfPkg: Obtain SEV encryption mask with the new MemEncryptSevLib APITom Lendacky2021-01-074-40/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* OvmfPkg/MemEncryptSevLib: Add an interface to retrieve the encryption maskTom Lendacky2021-01-0712-104/+400
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* OvmfPkg/ResetVector: Save the encryption mask at boot timeTom Lendacky2021-01-073-1/+12
| | | | | | | | | | | | | | | | | | 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>
* OvmfPkg/ResetVector: Perform a simple SEV-ES sanity checkTom Lendacky2021-01-071-0/+16
| | | | | | | | | | | | | | | | 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>
* OvmfPkg/ResetVector: Validate the encryption bit position for SEV/SEV-ESTom Lendacky2021-01-074-3/+136
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* OvmfPkg/Sec: Move SEV-ES SEC workarea definition to common header fileTom Lendacky2021-01-072-5/+17
| | | | | | | | | | | | | | | | 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>
* Ovmf/ResetVector: Simplify and consolidate the SEV features checksTom Lendacky2021-01-071-30/+45
| | | | | | | | | | | | | | | | | 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>
* OvmfPkg/VirtioFsDxe: call IsTimeValid() before EfiTimeToEpoch()Laszlo Ersek2021-01-071-6/+16
| | | | | | | | | | | | | | | | | | | | | | | 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>
* OvmfPkg/.azurepipelines: Enable EDK II CI for stable/* branchesMichael D Kinney2020-12-222-0/+4
| | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=3130 Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Bret Barkelew <Bret.Barkelew@microsoft.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* OvmfPkg/VirtioFsDxe: handle attribute updates in EFI_FILE_PROTOCOL.SetInfoLaszlo Ersek2020-12-211-1/+106
| | | | | | | | | | | | | 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>
* OvmfPkg/VirtioFsDxe: add helper for determining file mode bits updateLaszlo Ersek2020-12-213-0/+106
| | | | | | | | | | | | | | Add the VirtioFsGetFuseModeUpdate() function, for determining whether an EFI_FILE_PROTOCOL.SetInfo() invocation requests an update to the file mode bits. 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-48-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg/VirtioFsDxe: add helper for determining access time updatesLaszlo Ersek2020-12-212-0/+116
| | | | | | | | | | | | | | | Add the VirtioFsGetFuseTimeUpdates() function, for determining whether an EFI_FILE_PROTOCOL.SetInfo() invocation requests access time updates. 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-47-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com> [lersek@redhat.com: suppress bogus VS2019 warning about lack of initialization for ZeroTime]
* OvmfPkg/VirtioFsDxe: add helper for determining file size updateLaszlo Ersek2020-12-212-0/+48
| | | | | | | | | | | | | Add the VirtioFsGetFuseSizeUpdate() function, for determining whether an EFI_FILE_PROTOCOL.SetInfo() invocation requests a file size update. 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-46-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg/VirtioFsDxe: implement the wrapper function for FUSE_SETATTRLaszlo Ersek2020-12-214-1/+219
| | | | | | | | | | | | | Add the VirtioFsFuseSetAttr() function, for sending the FUSE_SETATTR command 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-45-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg/VirtioFsDxe: handle file rename/move in EFI_FILE_PROTOCOL.SetInfoLaszlo Ersek2020-12-211-1/+233
| | | | | | | | | | | | | | | 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>
* OvmfPkg/VirtioFsDxe: add helper for composing rename/move destination pathLaszlo Ersek2020-12-212-0/+202
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* OvmfPkg/VirtioFsDxe: implement the wrapper function for FUSE_RENAME2Laszlo Ersek2020-12-214-0/+156
| | | | | | | | | | | | | Add the VirtioFsFuseRename() function, for sending the FUSE_RENAME2 command 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-42-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg/VirtioFsDxe: handle the volume label in EFI_FILE_PROTOCOL.SetInfoLaszlo Ersek2020-12-211-1/+225
| | | | | | | | | | | | | | | | | | 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>
* OvmfPkg/VirtioFsDxe: implement EFI_FILE_PROTOCOL.Write()Laszlo Ersek2020-12-211-1/+62
| | | | | | | | | | | | | 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>
* OvmfPkg/VirtioFsDxe: implement the wrapper function for FUSE_WRITELaszlo Ersek2020-12-215-2/+196
| | | | | | | | | | | | | | | | 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>
* OvmfPkg/VirtioFsDxe: implement EFI_FILE_PROTOCOL.Flush()Laszlo Ersek2020-12-211-1/+25
| | | | | | | | | | | | | | | 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>
* OvmfPkg/VirtioFsDxe: implement EFI_FILE_PROTOCOL.Read() for directoriesLaszlo Ersek2020-12-211-1/+342
| | | | | | | | | | | | | | | | 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>
* OvmfPkg/VirtioFsDxe: add EFI_FILE_INFO cache fields to VIRTIO_FS_FILELaszlo Ersek2020-12-216-0/+42
| | | | | | | | | | | | | | | | | | | | | | | 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>
* OvmfPkg/VirtioFsDxe: convert FUSE dirent filename to EFI_FILE_INFOLaszlo Ersek2020-12-212-0/+85
| | | | | | | | | | | | | | | | | | | | 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>
* OvmfPkg/VirtioFsDxe: implement EFI_FILE_PROTOCOL.Read() for regular filesLaszlo Ersek2020-12-211-1/+74
| | | | | | | | | | | | | 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>
* OvmfPkg/VirtioFsDxe: add a shared wrapper for FUSE_READ / FUSE_READDIRPLUSLaszlo Ersek2020-12-215-4/+276
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* OvmfPkg/VirtioFsDxe: implement EFI_FILE_PROTOCOL.GetPosition, .SetPositionLaszlo Ersek2020-12-215-2/+50
| | | | | | | | | | | | | 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>
* OvmfPkg/VirtioFsDxe: implement EFI_FILE_PROTOCOL.GetInfo()Laszlo Ersek2020-12-212-1/+194
| | | | | | | | | | | | | | | 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>
* OvmfPkg/VirtioFsDxe: add helper for formatting UEFI basenamesLaszlo Ersek2020-12-212-0/+68
| | | | | | | | | | | | | | | 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-15 17:25:32 +0000