Re: [Qemu-devel] bundling edk2 platform firmware images with QEMU

["Daniel P. Berrangé" <berrange@redhat.com>]

On Fri, Mar 08, 2019 at 02:09:53PM +0100, Laszlo Ersek wrote:
> Hi,
> 
> I have a mostly-ready-for-posting patch set for $SUBJECT. My question is
> what QEMU release I should be targeting with it.
> 
> The Soft Feature Freeze for 4.0 is on 2019-03-12. Here's why that's a
> bit inconvenient for me.
> 
> The upcoming EDK2 stable release is edk2-stable201903, and it is planned
> for... today.
> 
>   https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning#edk2-stable201903-tag-planning
> 
> But, it's being blocked (at least one CVE fix still needs merging, but
> there could be something else too). I don't know what that will mean for
> the actual tag date. Maybe next Monday (the 11th)?
> 
> In my series, I'd like to advance QEMU's roms/edk2 submodule to this new
> release. But that might leave us with 1 day before the QEMU 4.0 Soft
> Feature Freeze (see above), i.e., for me to post the series, and for a
> submaintainer to send a pullreq with it. That's a bit too tight.

IMHO if you advanced the submodule hash to a nearly-released version
before freeze, it would be fine to then advance it again to the actually
released commit hash during QEMU freeze, because presumably the EDK
changes are similarly bugfix only at this point in its release process.

> 
> I'm not in a mortal rush to get this into 4.0, but the next release
> cycles (in three months, approximately?) might align similarly, between
> edk2 and QEMU. It would be best to avoid QEMU carrying edk2 platform
> firmware that is at all times at least three months old. The main reason
> is that CVEs tend to exist, for both edk2 proper, and for the specific
> OpenSSL release that is bundled with the given edk2 stable tag. And edk2
> doesn't yet have stable *branches*.
> 
> Should we try to squeeze my set into 4.0 (possibly moving the Soft
> Feature Freeze), or just aim for 4.1?
> 
> Also, who'd be the maintainer to queue my set? I mostly thought of Gerd,
> due to his work on iPXE and SeaBIOS. Here's the current diffstat:
> 
>  Makefile                                       |  17 +-
>  pc-bios/README                                 |  11 +
>  pc-bios/descriptors/50-edk2-i386-secure.json   |  34 +++
>  pc-bios/descriptors/50-edk2-x86_64-secure.json |  35 +++
>  pc-bios/descriptors/60-edk2-aarch64.json       |  31 +++
>  pc-bios/descriptors/60-edk2-arm.json           |  31 +++
>  pc-bios/descriptors/60-edk2-i386.json          |  33 +++
>  pc-bios/descriptors/60-edk2-x86_64.json        |  34 +++
>  pc-bios/edk2-aarch64-code.fd                   | Bin 0 -> 67108864 bytes
>  pc-bios/edk2-arm-code.fd                       | Bin 0 -> 67108864 bytes
>  pc-bios/edk2-arm-vars.fd                       | Bin 0 -> 67108864 bytes
>  pc-bios/edk2-i386-code.fd                      | Bin 0 -> 3653632 bytes
>  pc-bios/edk2-i386-secure-code.fd               | Bin 0 -> 3653632 bytes
>  pc-bios/edk2-i386-vars.fd                      | Bin 0 -> 540672 bytes
>  pc-bios/edk2-licenses.txt                      | 209 +++++++++++++++
>  pc-bios/edk2-x86_64-code.fd                    | Bin 0 -> 3653632 bytes
>  pc-bios/edk2-x86_64-secure-code.fd             | Bin 0 -> 3653632 bytes


Yikes, am I really reading those sizes right ? The biggest ROMs there
are 64 MB, so this is proposing to add ~206 MB of binaries to the
pc-bios directory ?

I think this is a very undesirable thing to do.

Consider that we'll need to refresh those ROMs multiple times a year to
track updates or security fixes. It will result in our .git repo size
growing massively over time. I don't think people will like cloning
multi-GB  sized repos after a few years of ROM updates.

As I've mentioned before, I think QEMU should get out of the business
of distributing ROMs in its primary released qemu-x.x.x.tar.gz archives,
and provide them as a separate tar.gz bundle. Even better if we can
move the existing ROMS out of git too, though we have to consider how
developers biulding from git would access the ROMs & know when they
need to acquire new copies.

The main important things to version control are the build config and
the git submodule version information.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|