sys-firmware / edk2

TianoCore EDK II UEFI firmware for virtual machines

Official package sites : https://github.com/tianocore/edk2 ·

v202408 :: 0 :: gentoo

Modified
License
BSD-2 MIT
Keywords
-* ~amd64 ~arm64
USE flags
secureboot

v202405 :: 0 :: gentoo

Modified
License
BSD-2 MIT
Keywords
-* ~amd64
USE flags
secureboot

v202202 :: 0 :: gentoo

Modified
License
BSD-2 MIT
Keywords
-* amd64
USE flags
secureboot

General

secureboot
Automatically sign efi executables using user specified key

sys-firmware / edk2-bin : TianoCore EDK II UEFI firmware for virtual machines

app-admin / mkosi : Build Bespoke OS Images

app-emulation / qemu : QEMU + Kernel-based Virtual Machine userland tools

sys-firmware / edk2-bin : TianoCore EDK II UEFI firmware for virtual machines

x11-misc / grub2-theme-preview : Preview a GRUB 2.x theme using KVM/QEMU

867772
sys-cluster/minikube: kvm2 driver uses wrong hardcoded paths for aarch64 efi firmware (sys-firmware/edk2)
921729
sys-firmware/edk2{,-bin}: multiple vulnerabilities
922253
sys-firmware/edk2{-bin,}: multiple vulnerabilities
Repository mirror & CI · gentoo
Merge updates from master
James Le Cuirot · gentoo
sys-firmware/edk2-ovmf-bin: Rename to edk2-bin to support other platforms
The source package now supports other platforms so follow suit. Signed-off-by: James Le Cuirot <chewi@gentoo.org>
James Le Cuirot · gentoo
sys-firmware/edk2: Add arm64 VM support to 202408
The filenames used here differ from Fedora, which ships far more variants. I felt it unnecessary to include the raw and unpadded images when the padded QCOW2 images should be all you need. QEMU_EFI.secboot_INSECURE.qcow2 does have Secure Boot enabled, but it must not be used in production. The lack of an SMM implementation for arm64 in this firmware means that the EFI variable store is unprotected, making the firmware unsafe. Signed-off-by: James Le Cuirot <chewi@gentoo.org>
James Le Cuirot · gentoo
sys-firmware/edk2: Add missing BDEPEND on sys-apps/which
The new version bump won't use this. Closes: https://bugs.gentoo.org/853271 Signed-off-by: James Le Cuirot <chewi@gentoo.org>
James Le Cuirot · gentoo
sys-firmware/edk2: Apply missing -Werror and hardened patches to 202405
Closes: https://bugs.gentoo.org/937610 Signed-off-by: James Le Cuirot <chewi@gentoo.org>
James Le Cuirot · gentoo
sys-firmware/edk2: Drop obsolete reference to USE=binary and update URL
I don't think using UefiShell.img actually works any more, but the new version bump will automatically create OVMF_VARS.secboot.fd for you. Closes: https://bugs.gentoo.org/926630 Signed-off-by: James Le Cuirot <chewi@gentoo.org>
James Le Cuirot · gentoo
sys-firmware/edk2-ovmf: Rename to edk2 to support other platforms
There is a lot of overlap in building firmware for other platforms from source, so it makes sense to have one source package. Signed-off-by: James Le Cuirot <chewi@gentoo.org>
James Le Cuirot · gentoo
sys-firmware/edk2: Bump to 202408, Python 3.13, many other improvements
The ebuild has been largely rewritten. It now: * Respects CC, CXX, and flags when building the base tools. * Doesn't use gcc/cc when building the firmware, enabling cross. * Prepares the ground for supporting platforms other than OVMF for x64. * Installs OVMF_VARS.secboot.fd prepared with virt-fw-vars. * Includes the latest UEFI DBX update in OVMF_VARS.secboot.fd. * Adds 4MB variants of the .fd images (in QCOW2 format). * Fixes network support broken by a recent bump. * Drops EnrollDefaultKeys.efi and UefiShell.img The enrollment tool hasn't actually worked for a while and is no longer needed now that we provide OVMF_VARS.secboot.fd. UefiShell.img is therefore of little use, and other distros now provide UefiShell.iso instead anyway. We can do the same if there is sufficient interest. This moves us closer to Fedora, but they ship far more variants. They have a large Python wrapper around upstream's build system, which is unusual in itself. Building all these would make the ebuild much more complex, take a long time, and use up more disk space. Perhaps USE flags could help here, but I'm not sure what all these variants are for. I also decided to install to paths based on upstream's names, e.g. edk2/ArmVirtQemu-AARCH64 as opposed to Fedora's edk2/aarch64 because mixing QEMU with Xen and others would be confusing when there are many similarly named files, even within a single architecture. Closes: https://bugs.gentoo.org/891191 Closes: https://bugs.gentoo.org/921819 Closes: https://bugs.gentoo.org/929838 Signed-off-by: James Le Cuirot <chewi@gentoo.org>