[Bug 1852196] Re: update edk2 submodule & binaries to edk2-stable201911

[Laszlo Ersek (Red Hat)]

Yes, I do have a reason for delaying this LP until after 4.2.0 is out.

When I filed this ticket (on 2019-Nov-12), QEMU had already entered the
4.2.0 soft feature freeze (on 2019-Oct-29). Despite possible
appearances, this LP is actually a feature addition -- that's why I also
set "Tags: feature-request" when I filed this LP.

The reason this is not a fix but a feature addition is the following:
- CVE-2019-14553 is irrelevant (doesn't exist) until we enable HTTPS Boot,
- we have not enabled HTTPS Boot earlier exactly because of CVE-2019-14553,
- the plan is to enable HTTPS Boot now, with CVE-2019-14553 fixed,
- so what remains are CVE-2019-1543, CVE-2019-1552 and CVE-2019-1563, which are 
native OpenSSL problems.

The upstream edk2 project advanced to OpenSSL 1.1.1d because of the last
point (i.e. because of those three OpenSSL CVEs). That submodule update
was tracked in:

https://bugzilla.tianocore.org/show_bug.cgi?id=2226

As you can see:

(1) there was zero analysis or explanation how those OpenSSL CVEs would
*actually* affect edk2 platforms,

(2) edk2 advanced to OpenSSL 1.1.1d (on 2019-Nov-05) approximately two
months after upstream OpenSSL 1.1.1d was released (on 2019-Sep-10).

Furthermore,

(3) all the listed CVEs are marked "low severity":

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-1543
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-1552
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-1563

(The first two items are declared low severity on cve.mitre.org, while
the last item is declared low severity in
<https://www.openssl.org/news/secadv/20190910.txt>.)

These points (1) through (3) tell me that the edk2 advance was more or
less "better safe than sorry" or "cargo cult".

While that approach is not necessarily wrong, if you have infinite
amounts of time, my capacity falls near the other end of the spectrum.
If someone runs QEMU in production, they should build their firmware
from source anyway -- the bundling of edk2 binaries with QEMU is a
convenience.

If you'd like to submit a QEMU patch set (just for the sake of the CVE
fixes, not the HTTPS Boot feature), and are willing to make the case for
getting that into 4.2-rc4, I won't block it, but I don't think it's
worth the churn, to be honest.

Thanks!
Laszlo

** Bug watch added: bugzilla.tianocore.org/ #2226
   https://bugzilla.tianocore.org/show_bug.cgi?id=2226

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2019-14553

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2019-1543

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2019-1552

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2019-1563

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1852196

Title:
  update edk2 submodule & binaries to edk2-stable201911

Status in QEMU:
  New

Bug description:
  edk2-stable201911 will be tagged soon:

    https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-
  Release-Planning

    https://github.com/tianocore/edk2/releases/tag/edk2-stable201911
    [upcoming link]

  It should be picked up by QEMU, after the v4.2.0 release.

  Relevant fixes / features in edk2, since edk2-stable201905 (which is
  what QEMU bundles at the moment, from LP#1831477):

  - enable UEFI HTTPS Boot in ArmVirtQemu* platforms
    https://bugzilla.tianocore.org/show_bug.cgi?id=1009
    (this is from edk2-stable201908)

  - fix CVE-2019-14553 (Invalid server certificate accepted in HTTPS Boot)
    https://bugzilla.tianocore.org/show_bug.cgi?id=960

  - consume OpenSSL-1.1.1d, for fixing CVE-2019-1543, CVE-2019-1552 and
    CVE-2019-1563
    https://bugzilla.tianocore.org/show_bug.cgi?id=2226

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1852196/+subscriptions