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

[Daniel P . Berrangé]

On Fri, Mar 08, 2019 at 01:42:11PM +0000, Daniel P. Berrangé wrote:
> 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.

Oh, and the json firmware description files make sense. Even without
the blobs, those metadata files set guidance on what variants of EDK
a vendor should aim to ship and can likely be used "as-is" by the
vendor's own downstream firmware biulds.


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 :|