update edk2 submodule & binaries to edk2-stable202008

[Laszlo Ersek (Red Hat)]

Consume the following upstream edk2 releases:

https://github.com/tianocore/edk2/releases/tag/edk2-stable201908
https://github.com/tianocore/edk2/releases/tag/edk2-stable201911
https://github.com/tianocore/edk2/releases/tag/edk2-stable202002
https://github.com/tianocore/edk2/releases/tag/edk2-stable202005
https://github.com/tianocore/edk2/releases/tag/edk2-stable202008

Worth mentioning (in random order):

- various CVE fixes [*]
- OpenSSL-1.1.1g
- UEFI HTTPS Boot for ARM/AARCH64
- TPM2 for ARM/AARCH64
- VCPU hotplug with SMI
- support for Linux v5.7+ initrd and mixed mode loading
- Fusion-MPT SCSI driver in OVMF
- VMware PVSCSI driver in OVMF
- PXEv4 / PXEv6 boot possible to disable on the QEMU command line
- SEV-ES support

[*] the below list has been collected simply from the subject lines in
commit range edk2-stable201905..edk2-stable202008:

  CVE-2019-11098 CVE-2019-14553 CVE-2019-14558 CVE-2019-14559
  CVE-2019-14562 CVE-2019-14563 CVE-2019-14575 CVE-2019-14586
  CVE-2019-14587

(Note that any given CVE from the above list may or may not affect the
firmware binaries packaged with upstream QEMU; consult the upstream
TianoCore bug tracker at <https://bugzilla.tianocore.org/> for details.)

[Philippe Mathieu-Daudé (philmd)]

Hi Laszlo,

Do you have a particular reason to update the submodule *after* the v4.2.0 release?
I'd rather see QEMU 4.2 released with edk2-stable201911, as it fixes various CVE (therefore a patch for 4.2-rc4 seems acceptable to me).

[Laszlo Ersek (Red Hat) (lersek)]

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

[Laszlo Ersek (Red Hat) (lersek)]

Posted

* [qemu-devel] [PATCH 00/10] edk2: adopt the edk2-stable202008 release

http://<email address hidden>

[Philippe Mathieu-Daudé (philmd)]

Commit a68694cd1f3.

[Thomas Huth (th-huth)]

Released with QEMU v5.2.0.