Re: roms/efirom, tests/uefi-test-tools: update edk2's own submodules first

[Daniel P . Berrangé]

On Wed, Oct 21, 2020 at 02:05:18PM +0200, Laszlo Ersek wrote:
> On 10/20/20 11:54, Philippe Mathieu-Daudé wrote:
> > On 10/20/20 11:44 AM, Daniel P. Berrangé wrote:
> >> On Tue, Oct 20, 2020 at 11:29:01AM +0200, Philippe Mathieu-Daudé wrote:
> >>> Hi Olaf,
> >>>
> >>> On 10/20/20 11:16 AM, Olaf Hering wrote:
> >>>> This is about qemu.git#ec87b5daca761039bbcf781eedbe4987f790836f
> >>>>
> >>>> On Mon, Sep 07, Laszlo Ersek wrote:
> >>>>
> >>>>> In edk2 commit 06033f5abad3 ("BaseTools: Make brotli a submodule",
> >>>>> 2020-04-16), part of edk2-stable202005, the Brotli compressor /
> >>>>> decompressor source code that edk2 had flattened into BaseTools was
> >>>>> replaced with a git submodule.
> >>>>>
> >>>>> This means we have to initialize edk2's own submodules before building
> >>>>> BaseTools not just in "roms/Makefile.edk2", but in "roms/Makefile"
> >>>>> (for
> >>>>> the sake of the "efirom" target) and
> >>>>> "tests/uefi-test-tools/Makefile" as
> >>>>> well.
> >>>>
> >>>>> +++ b/roms/Makefile
> >>>>>    edk2-basetools:
> >>>>> +    cd edk2/BaseTools && git submodule update --init --force
> >>>>>    build-edk2-tools:
> >>>>> +    cd $(edk2_dir)/BaseTools && git submodule update --init --force
> >>>>
> >>>>
> >>>> This change can not possibly be correct.
> >>>>
> >>>> With current qemu.git#master one is forced to have network access to
> >>>> build the roms. This fails with exported (and complete) sources in an
> >>>> offline environment.
> >>>
> >>> The EDK2 roms are only used for testing, we certainly don't want them
> >>> to be used by distributions. I suppose the question is "why is this
> >>> rule called if tests are not built?".
> >>
> >> I don't believe that is correct - the pc-bios/edk*  ROMs and the
> >> corresponding  pc-bios/descriptor files are there for real world
> >> end user consumption.   roms/edk2 should (must) match / reflect
> >> the content used to build the pci-bios/edk* blobs.
> >>
> >> Many distros have a policy requiring them to build everything
> >> from source, so they will ignore the pre-built edk2 ROMs, but
> >> regular end users taking QEMU directly from upstream can certainly
> >> use our edk2 ROMs.
> > 
> > Well I'm lost (and I don't think mainstream QEMU have the
> > bandwidth to follow mainstream EDK2 security fixes) so I'm
> > giving up, waiting for clarification from Laszlo.
> 
> I definitely don't have time for keeping the edk2 blobs bundled with
> QEMU fresh wrt. security fixes in upstream edk2, so anyone expecting
> that is in for a bad surprise. The blobs are provided, from my
> perspective, (a) for some tests in the test suite (such as
> bios-tables-test for the aarch64 target), (b) as a convenience for
> end-users that desire to build QEMU from source, without wanting to
> build OVMF from source.

The issue with security is not unique to EDK2. Essentially all the
binary blob firmwares that QEMU distributes have this problem, since
we dont update any of them in response to upstream security issues
in any reliable timeframe.  EDK2 is probably most dangerous since
its code base is relatively larger than other firmwares, but they
are all essentially doomed.

This is why distros should generall ybuild as many of the ROMs as
possible from scratch using latest available upstream source, not
what QEMU distributes.

I wish we would actually ship a qemu tarball which excluded all the
pre-built ROMs and bundle them in a separate add-on tarball, with a
warning that they shouldn't be used in any "virtualization" use case
in production, only for non-virtualization use cases, as described in

  https://www.qemu.org/docs/master/system/security.html

because the latter is where security does not matter.

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