summaryrefslogtreecommitdiffstats
path: root/OvmfPkg/Library/X86QemuLoadImageLib
Commit message (Collapse)AuthorAgeFilesLines
* OvmfPkg/X86QemuLoadImageLib: Handle allocation failure for CommandLineMartin Radev2021-03-191-0/+10
| | | | | | | | | | | | | | | | The CommandLine and InitrdData may be set to NULL if the provided size is too large. Because the zero page is mapped, this would not cause an immediate crash but can lead to memory corruption instead. This patch just adds validation and returns error if either allocation has failed. Signed-off-by: Martin Radev <martin.b.radev@gmail.com> Message-Id: <YFPJsaGzVWQxoEU4@martin-ThinkPad-T440p> Acked-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Tom Lendacky <thomas.lendacky@amd.com> [lersek@redhat.com: drop unnecessary empty line from code; remove personal (hence likely unstable) repo reference from commit message] Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/X86QemuLoadImageLib: handle EFI_ACCESS_DENIED from LoadImage()Laszlo Ersek2020-06-091-4/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* OvmfPkg/X86QemuLoadImageLib: add dummy assignment to work around GCCArd Biesheuvel2020-03-261-0/+5
| | | | | | | | | | | | | | | | | | | | | GCC 4.8 or 4.9 may throw the following error when building OVMF: Edk2/OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.c: In function ‘QemuLoadKernelImage’: Edk2/OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.c:416:30: error: ‘CommandLine’ may be used uninitialized in this function [-Werror=maybe-uninitialized] UnicodeSPrintAsciiFormat ( cc1: all warnings being treated as errors This is due to the fact that older GCCs fail to infer that CommandLine is never actually used unless it has been assigned. So add a redundant NULL assignment to help these older GCCs understand this. Link: https://bugzilla.tianocore.org/show_bug.cgi?id=2630 Fixes: 7c47d89003a6f ("OvmfPkg: implement QEMU loader library for X86 with ...") Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Fix build failure with VS2015 tool chainLiming Gao2020-03-171-1/+1
| | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2582 warning C4244: '=': conversion from 'UINTN' to 'UINT32', possible loss of data With this fix, OvmfIa32, OvmfX64 and OvmfIa32X64 can pass build. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/X86QemuLoadImageLib: fix "unused variable" error in X64 DXE buildsLaszlo Ersek2020-03-081-1/+2
| | | | | | | | | | | | | | | | | | | | | When the MDE_CPU_IA32 macro is not defined, there is no access to the "KernelImageHandle" local variable in QemuStartKernelImage(). This breaks the OvmfPkgIa32X64 and OvmfPkgX64 platform builds, at least with gcc-8. Move the local variable to the inner scope, where declaration and usage are inseparable. (Note that such inner-scope declarations are frowned upon in the wider edk2 codebase, but we use them liberally in ArmVirtPkg and OvmfPkg anyway, because they help us reason about variable lifetime and visibility.) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Fixes: 7c47d89003a6f8f7f6f0ce8ca7d3e87c630d14cc Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2572 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg: implement QEMU loader library for X86 with legacy fallbackArd Biesheuvel2020-03-052-0/+609
Implement another version of QemuLoadImageLib that uses LoadImage and StartImage, but falls back to the legacy Linux loader code if that fails. The logic in the legacy fallback routines is identical to the current QEMU linux loader for X64 and IA32. Note the use of the OVMF_LOADED_X86_LINUX_KERNEL protocol for the legacy loaded image: this makes it possible to expose the LoadImage/StartImage abstraction for the legacy loader, using the EFI paradigm of identifying a loaded image solely by a handle. 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>