summaryrefslogtreecommitdiffstats
path: root/OvmfPkg/QemuKernelLoaderFsDxe
Commit message (Collapse)AuthorAgeFilesLines
* AmdSev: Halt on failed blob allocationTobin Feldman-Fitzthum2024-06-251-5/+4
| | | | | | | | | | | | A malicious host may be able to undermine the fw_cfg interface such that loading a blob fails. In this case rather than continuing to the next boot option, the blob verifier should halt. For non-confidential guests, the error should be non-fatal. Signed-off-by: Tobin Feldman-Fitzthum <tobin@linux.ibm.com>
* OvmfPkg: Update code to be more C11 compliant by using __func__Rebecca Cran2023-04-101-6/+6
| | | | | | | | | | | | | __FUNCTION__ is a pre-standard extension that gcc and Visual C++ among others support, while __func__ was standardized in C99. Since it's more standard, replace __FUNCTION__ with __func__ throughout OvmfPkg. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
* OvmfPkg: Apply uncrustify changesMichael Kubacki2021-12-071-158/+205
| | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3737 Apply uncrustify changes to .c/.h files in the OvmfPkg package Cc: Andrew Fish <afish@apple.com> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Andrew Fish <afish@apple.com>
* OvmfPkg/QemuKernelLoaderFsDxe: call VerifyBlob after fetch from fw_cfgDov Murik2021-07-291-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In QemuKernelLoaderFsDxeEntrypoint we use FetchBlob to read the content of the kernel/initrd/cmdline from the QEMU fw_cfg interface. Insert a call to VerifyBlob after fetching to allow BlobVerifierLib implementations to add a verification step for these blobs. This will allow confidential computing OVMF builds to add verification mechanisms for these blobs that originate from an untrusted source (QEMU). The null implementation of BlobVerifierLib does nothing in VerifyBlob, and therefore no functional change is expected. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ashish Kalra <ashish.kalra@amd.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3457 Co-developed-by: James Bottomley <jejb@linux.ibm.com> Signed-off-by: James Bottomley <jejb@linux.ibm.com> Signed-off-by: Dov Murik <dovmurik@linux.ibm.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* Revert "OvmfPkg/QemuKernelLoaderFsDxe: don't expose kernel command line"Dov Murik2021-06-291-3/+8
| | | | | | | | | | | | | | | | | | | | | | This reverts commit efc52d67e1573ce174d301b52fa1577d552c8441. Manually fixed conflicts in: OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.c Note that besides re-exposing the kernel command line as a file in the synthetic filesystem, we also revert back to AllocatePool instead of AllocatePages. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Tobin Feldman-Fitzthum <tobin@linux.ibm.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3457 Signed-off-by: Dov Murik <dovmurik@linux.ibm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20210628105110.379951-4-dovmurik@linux.ibm.com> Tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/QemuKernelLoaderFsDxe: drop tentative const object definitionArd Biesheuvel2020-03-081-66/+71
| | | | | | | | | | | | | | | | | | | Bob reports that VS2017 chokes on a tentative definition of the const object 'mEfiFileProtocolTemplate', with the following error: OvmfPkg\QemuKernelLoaderFsDxe\QemuKernelLoaderFsDxe.c(130): error C2220: warning treated as error - no 'object' file generated OvmfPkg\QemuKernelLoaderFsDxe\QemuKernelLoaderFsDxe.c(130): warning C4132: 'mEfiFileProtocolTemplate': const object should be initialized Let's turn the only function that relies on this tentative definition into a forward declaration itself, and move its definition after the external definition of the object. That allows us to drop the tentative definition of the const object, and hopefully make VS2017 happy. Cc: "Feng, Bob C" <bob.c.feng@intel.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/QemuKernelLoaderFsDxe: add support for new Linux initrd device pathArd Biesheuvel2020-03-052-0/+81
| | | | | | | | | | | | Linux v5.7 will introduce a new method to load the initial ramdisk (initrd) from the loader, using the LoadFile2 protocol installed on a special vendor GUIDed media device path. Add support for this to our QEMU command line kernel/initrd loader. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2566 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/QemuKernelLoaderFsDxe: add support for the kernel setup blockArd Biesheuvel2020-03-051-21/+53
| | | | | | | | | | | | | | | | On x86, the kernel image consists of a setup block and the actual kernel, and QEMU presents these as separate blobs, whereas on disk (and in terms of PE/COFF image signing), they consist of a single image. So add support to our FS loader driver to expose files via the abstract file system that consist of up to two concatenated blobs, and redefine the kernel file so it consists of the setup and kernel blobs, on every architecture (on non-x86, the setup block is simply 0 bytes and is therefore ignored implicitly) Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2566 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/QemuKernelLoaderFsDxe: don't expose kernel command lineArd Biesheuvel2020-03-051-4/+3
| | | | | | | | | | | We have no need for exposing the kernel command line as a file, so remove support for that. Since the remaining blobs (kernel and initrd) are typically much larger than a page, switch to the page based allocator for blobs at the same time. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2566 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: export abstract QEMU blob filesystem in standalone driverArd Biesheuvel2020-03-052-0/+1027
Expose the existing implementation of an abstract filesystem exposing the blobs passed to QEMU via the command line via a standalone DXE driver. Notable difference with the original code is the switch to a new vendor GUIDed media device path, as opposed to a vendor GUID hardware device path, which is not entirely appropriate for pure software constructs. Since we are using the GetTime() runtime service in a DXE_DRIVER type module, we need to DEPEX explicitly on gEfiRealTimeClockArchProtocolGuid. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2566 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-21 14:34:05 +0000