Comment 0 for bug 1570617

Revision history for this message
dann frazier (dannf) wrote :

[Availability]
Pending upload of 0~20160408 upstream snapshot release (in progress: http://anonscm.debian.org/cgit/pkg-qemu/edk2.git)

[Rationale]
edk2 provides EFI ROM images to be used by KVM VMs. On x86 this can be used as an alternative to seabios. On arm64, however, there is no "seabios" option - edk2 is the *only* way to boot an arm64 guest using the kernel/ramdisk configured in the image. Without edk2, users have to manually extract the kernel/ramdisk/cmdline from the cloud image and provide them externally to qemu. This obviously isn't a reasonable way to e.g. manage OpenStack instances, as the kernel/ramdisk would have to be re-extracted and reconfigured on every kernel security update. We'd therefore like to be able to have qemu-system-x86 and qemu-system-arm depend on the corresponding edk2 binary for the architecture.

edk2 is currently in multiverse due to a licensing restriction on the FAT driver code. Microsoft has recently removed the non-DFSG restriction.

[Security]
edk2 had a couple of CVEs assigned in 2014: CVE-2014-4859, CVE-2014-4860, but it looks like those were the only 2.

[Quality assurance]
The binary packages don't require any configuration - they're basically just providing data files that can optionally be used by QEMU.

[Dependencies]
All build deps are in main, and all produced binary packages have no runtime dependencies.

[Standards compliance]
EDK2 is the sample implementation for UEFI from Intel - de facto standards-compliant.

[Maintenance]
Canonical supports OpenStack on arm64, for which this is a key component. Linaro is actively maintaining the virt bits upstream, and Canonical's HWE and Foundations team are maintaining the package for that purpose.

[Background information]