summaryrefslogtreecommitdiffstats
path: root/meta/recipes-core/ovmf/ovmf
AgeCommit message (Collapse)Author
2023-09-18ovmf: update edk2-stable202305 -> edk2-stable202308Alexander Kanavin
Signed-off-by: Alexander Kanavin <alex@linutronix.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2023-06-27ovmf: update 202302 -> 202305Alexander Kanavin
Signed-off-by: Alexander Kanavin <alex@linutronix.de> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2023-05-22ovmf: update 202211 -> 202302Alexander Kanavin
Signed-off-by: Alexander Kanavin <alex@linutronix.de> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2022-12-21ovmf: update edk2-stable202208 -> edk2-stable202211Alexander Kanavin
Signed-off-by: Alexander Kanavin <alex@linutronix.de> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2022-11-01ovmf: correct patches statusAlexander Kanavin
Signed-off-by: Alexander Kanavin <alex@linutronix.de> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2022-09-02ovmf: drop the force no-stack-protector patchAlexander Kanavin
This should not be necessary, as ovmf is already marked as COMPATIBLE_HOST:class-target='(i.86|x86_64).*' and existing upstream code handles both. If/when ovmf is used on other targets, the situation can be revisited. Signed-off-by: Alexander Kanavin <alex@linutronix.de> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2022-06-07ovmf: update 202202 -> 202205Alexander Kanavin
Signed-off-by: Alexander Kanavin <alex@linutronix.de> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2022-05-15ovmf: Fix native build with gcc-12Khem Raj
Host distros have started deploying gcc12 as well e.g. archlinux this build failure shows up which has been fixed upstream In function ‘GetAlignmentFromFile’, inlined from ‘main’ at GenFfs.c:816:20: GenFfs.c:545:5: error: pointer ‘InFileHandle’ used after ‘fclose’ [-Werror=use-after-free] 545 | Error(NULL, 0, 4001, "Resource", "memory cannot be allocated of %s", InFileHandle); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2022-03-02ovmf: upgrade 202111 -> 202202wangmy
0001-Fix-VLA-parameter-warning.patch removed since it's included in 202202 Changelog: ========= OvmfPkg Add new target for Cloud Hypervisor Add TDVF to OvmfPkg Add new APIs to UefiCpuPkg/UefiCpuLib Add AMD Secure Nested Paging Support Add SSDT PCI generator in DynamicTablesPkg Support ACPI 6.4 PPTT changes Add FdtHwInfoParser library Add DynamicPlatRepo library Make package and platform builds reproducible across source format changes Add Uncrustify CI Plugin Apply uncrustify changes to all package C and H files Signed-off-by: Wang Mingyu <wangmy@fujitsu.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2021-11-29ovmf: remove patch merged upstreamAlexander Kanavin
See here: https://github.com/tianocore/edk2/pull/1513/files The change was thus applied twice to the same file. Signed-off-by: Alexander Kanavin <alex@linutronix.de>
2021-11-21ovmf: submit patch upstreamAlexander Kanavin
Signed-off-by: Alexander Kanavin <alex@linutronix.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2021-11-11ovmf: submit patch upstreamAlexander Kanavin
Signed-off-by: Alexander Kanavin <alex@linutronix.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2021-06-17ovmf: update 2021.02 -> 2021.05Alexander Kanavin
Reformat patches using git, so that rebasing them to newer versions is easier. Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2021-05-31ovmf: Fix VLA warnings with GCC 11Khem Raj
Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2021-05-13ovmf: Fix other reproducibility issuesRichard Purdie
When building in longer paths, the ovmf build changes in many ways. This adds a patch addressing various causes of problems. Full details are in the patch header. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2021-05-11ovmf: Improve reproducibility by enabling prefix mappingRichard Purdie
We want to pass ${DEBUG_PREFIX_MAP} to gcc commands and also pass in --debug-prefix-map to nasm (we carry a patch to nasm for this). The tools definitions are built by ovmf-native so we need to pass this in at target build time when we know the right values. By using determininistc file paths in the ovmf build, it removes the opportunitity for gcc/ld to change the output binaries due to path lengths overflowing section sizes and causing small changes in the binary output. This also means that if builds have reproducibility issues in future, it becomes much easier to compare intermediate build artefacts. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2021-03-16ovmf: make output binaries reproducibleRoss Burton
OVMF is mostly reproducible, but the final .efi binaries have a 'NM10' segment in that references the original input file, and this input file has the build path in. This can be solved by passing --zero to GenFw so that this segment is zero'd out in release builds. [ YOCTO #14264 ] Signed-off-by: Ross Burton <ross.burton@arm.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2021-03-14ovmf: upgrade 202011 -> 202102Wang Mingyu
0003-ovmf-enable-long-path-file.patch removed since it is not available in 202102. Signed-off-by: Wang Mingyu <wangmy@cn.fujitsu.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2020-10-30ovmf: update edk2-stable202005 -> edk2-stable202008Alexander Kanavin
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2020-05-07ovmf: update to 202002Alexander Kanavin
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2020-01-10ovmf: update to 201911Alexander Kanavin
Remove unused patch. Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
2019-08-08ovmf: Update to version edk2-stable201905Ricardo Neri
Fixes [YOCTO #13438] Update OVMF to edk2-stable201905. Since the last update, several things have changed. Many of the patches we were carrying have now been taken upstream in EDK2 or become obsolete. See below for details. Also, as of commit 0c1ffb9504c3("CryptoPkg: Adding OpenSSL as one submodule of EDKII repo"), openssl is not embedded into EDK2 using a patching script but a git submodule. Then, use the gitsm bitbabke fetcher and drop the extra SRC_URI from openssl when building with secureboot enabled. Also remove all related variables. OVMF switched to BSD+Patent license as detailed in https://bugzilla.tianocore.org/show_bug.cgi?id=1373. Hence, update LIC_FILES_CHKSUM accordingly to reflect this change. Patches are updated as follows: Drop 0001-ia32-Dont-use-pie.patch as it is implemented in upstream EDK2 in commits are 11d0cd23dd1b ("BaseTools/tools_def IA32: drop -no-pie linker option for GCC49" and c25d3905523a ("BaseTools/tools_def IA32: disable PIE code generation explicitly") for the applicable GCC versions. Rebase 0003-BaseTools-makefile-adjust-to-build-in-under-bitbake.patch to edk2-stable201905. Drop VfrCompile-increase-path-length-limit.patch as it has been taken upstream in EDK2 in commit ba78032bc8c9f("BaseTools/VfrCompile: Remove the MAX_PATH limitation"). Rebase no-stack-protector-all-archs.patch to keep behavior on not using stack protector on all archs. Drop 0001-BaseTools-header.makefile-add-Wno-stringop-truncatio.patch, 0002-BaseTools-header.makefile-add-Wno-restrict.patch, and 0003-BaseTools-header.makefile-revert-gcc-8-Wno-xxx-optio.patch. These patches have been taken in upstream EDK2 in commits 9222154ae7b3("BaseTools /header.makefile: add "-Wno-restrict"), 1d212a83df0e("BaseTools/ header.makefile: add "-Wno-stringop-truncation"), and 777f4aa083e9 ("BaseTools/header.makefile: revert gcc-8 '-Wno-xxx' options on OSX"), respectively. Also, drop 0004-BaseTools-GenVtf-silence-false-stringop-overflow-war.patch. GenVtf has been removed from EDK2 in commit 64ab2c82e8f6("BaseTools: Remove GenVtf"). Also, this patch had been taken in EDK2 upstream in commit 9de306701312("BaseTools/GenVtf: silence false 'stringop-overflow' warning with memcpy()"). Drop patch 0007-OvmfPkg-EnrollDefaultKeys-application-for-enrolling-.patch as it also has been taken by EDK2. Patches 0002-ovmf-update-path-to-native-BaseTools.patch and 0004-ovmf-enable-long-path-file.patch did not need any update. Lastly, add a needed dependency on bc. Cc: Ross Burton <ross.burton@intel.com> Cc: Patrick Ohly <patrick.ohly@intel.com> Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
2018-05-29ovmf: Fix build with gcc8Khem Raj
Signed-off-by: Khem Raj <raj.khem@gmail.com>
2018-03-07ovmf: refresh patchesRoss Burton
The patch tool will apply patches by default with "fuzz", which is where if the hunk context isn't present but what is there is close enough, it will force the patch in. Whilst this is useful when there's just whitespace changes, when applied to source it is possible for a patch applied with fuzz to produce broken code which still compiles (see #10450). This is obviously bad. We'd like to eventually have do_patch() rejecting any fuzz on these grounds. For that to be realistic the existing patches with fuzz need to be rebased and reviewed. Signed-off-by: Ross Burton <ross.burton@intel.com>
2017-09-18ovmf: fix do_compile error when len(tmp)=410Dengke Du
[YOCTO #11354] (From OE-Core rev: b6f344bd311faca36cb3a4acdafac2728409ad90) Signed-off-by: Dengke Du <dengke.du@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-07-08ovmf: Fix build with toolchain defaulting to PIEKhem Raj
GCC44_IA32_X64_DLINK_COMMON and GCC49_IA32_X64_DLINK_COMMON variables add to final linker flags that ovmf build forms on its own, so trying to inject it from environment will not work. Here we add option to disable pie during linking, which should have been accompanied with correcponding gcc/cflags. Fixes | /mnt/a/oe/build/tmp/work/i586-bec-linux/ovmf/git-r0/git/Build/OvmfIa32/RELEASE_GCC5/IA32/OvmfPkg/AcpiTables/AcpiTables/OUTPUT/./Facs.dll: Bad definition for symbol '<unknown>'@0 or unsupported symbol type. For example, absolute and undefined symbols are not supported. Signed-off-by: Khem Raj <raj.khem@gmail.com>
2017-06-27meta: Add/fix missing Upstream-Status to patchesRichard Purdie
This adds or fixes the Upstream-Status for all remaining patches missing it in OE-Core. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-06-14ovmf: Update to latestKhem Raj
Fix build with gcc7 clang can not compile it therefore mark it gcc only recipe Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2017-05-10ovmf: Fix build with gcc7Khem Raj
backport a patch which fixing warnings with gcc7 Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2017-03-21ovmf: fix toolchain selectionPatrick Ohly
For the native tools, a static patch inserted gcc/g++/ld/ar while later adding BUILD_LDFLAGS and BUILD_CFLAGS with sed. Now it's all done with sed, which has the advantage that it uses the actual compile variables. However, in practice those are the same. More importantly, picking the build tools for the target was broken. ovmf-native tried to insert TARGET_PREFIX into the tools definition file, but that variable is empty in a native recipe. As a result, "gcc" was used instead of "${HOST_PREFIX}gcc", leading to an undesirable dependency on the host compiler and potentially (probably?!) causing some of the build issues that were seen for ovmf. The new approach is to override the tool selection in ovmf-native so that the HOST_PREFIX env variable is used, which then gets exported during do_compile for the target. While at it, Python code that gets appened to do_patch only to call shell functions gets replaced with the do_patch[postfuncs] mechanism. Incremental builds now always use the tools definition from the current ovmf-native; previously, only the initial build copied the template file. Probably the entire split into ovmf-native and ovmf could be removed. This merely hasn't been attempted yet. Signed-off-by: Patrick Ohly <patrick.ohly@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2017-02-28ovmf: increase path length limitPatrick Ohly
The VfrCompile tool has a hard-coded maximum length for path names which turned out to be too small by around 20 characters in the Yocto autobuilder setup. Increasing the maximum by a factor of 4 is relatively easy and makes the problem less likely. Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
2017-02-28ovmf: remove BGRT patchPatrick Ohly
This patch was added to meta-luv for kernel testing purposes and probably is not relevant for OE-core. Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
2017-02-28ovmf: build image which enrolls standard keysPatrick Ohly
When booting a qemu virtual machine with ovmf.secboot, it comes up with no keys installed and thus Secure Boot disabled. To lock down the machine like a typical PC, one has to enroll the same keys that PC vendors normally install, i.e. the ones from Microsoft. This can be done manually (see https://wiki.ubuntu.com/SecurityTeam/SecureBoot and https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_into_UEFI_Secure_Boot_White_Paper.pdf) or automatically with the EnrollDefaultKeys.efi helper from the Fedora ovmf rpm. To use this with qemu: $ bitbake ovmf-shell-image ... $ runqemu serial nographic qemux86 ovmf-shell-image wic ovmf.secboot ... UEFI Interactive Shell v2.1 EDK II UEFI v2.60 (EDK II, 0x00010000) Mapping table FS0: Alias(s):HD2b:;BLK4: PciRoot(0x0)/Pci(0x5,0x0)/HD(1,GPT,06AEF759-3982-4AF6-B517-70BA6304FC1C,0x800,0x566C) BLK0: Alias(s): PciRoot(0x0)/Pci(0x1,0x0)/Floppy(0x0) BLK1: Alias(s): PciRoot(0x0)/Pci(0x1,0x0)/Floppy(0x1) BLK2: Alias(s): PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0) BLK3: Alias(s): PciRoot(0x0)/Pci(0x5,0x0) Press ESC in 1 seconds to skip startup.nsh or any other key to continue. Shell> fs0:EnrollDefaultKeys.efi info: SetupMode=1 SecureBoot=0 SecureBootEnable=0 CustomMode=0 VendorKeys=1 info: SetupMode=0 SecureBoot=1 SecureBootEnable=1 CustomMode=0 VendorKeys=0 info: success Shell> reset Remember that this will modify deploy/images/qemux86/ovmf.secboot.qcow2, so make a copy and use the full path of that copy instead of the "ovmf" argument if needed. The ovmf-shell-image contains an EFI shell, which is what got started here directly. After enrolling the keys, Secure Boot is active and the same image cannot be booted anymore, so the BIOS goes through the normal boot targets (including network boot, which can take a while to time out), and ends up in the internal EFI shell. Trying to invoke bootia32.efi (the shell from the image) or EnrollDefaultKeys.efi then fails: Shell> bootia32.efi Command Error Status: Security Violation The main purpose at the moment is to test that Secure Boot enforcement really works. If we had a way to sign generated images, that part could also be tested by booting in a locked down qemu instance. 0007-OvmfPkg-EnrollDefaultKeys-application-for-enrolling-.patch is from https://src.fedoraproject.org/cgit/rpms/edk2.git/tree/0007-OvmfPkg-EnrollDefaultKeys-application-for-enrolling-.patch?id=b1781931894bf2057464e634beed68b1e3218c9e with one line changed to fix https://bugzilla.redhat.com/show_bug.cgi?id=132502: "EFI_STATUS Status = EFI_SUCCESS;" in EnrollListOfX509Certs() lacked the initializer. Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
2017-02-28ovmf: move from meta-luv to OE-coremeta-luv
This is an unmodified copy of github.com/01org/luv-yocto/meta-luv/recipes-core/ovmf revision 4be4329. Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>