From: Laszlo Ersek <lersek@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: "Paolo Bonzini" <pbonzini@redhat.com>,
"Olaf Hering" <olaf@aepfle.de>,
"Philippe Mathieu-Daudé" <philmd@redhat.com>,
qemu-devel@nongnu.org,
"Marc-André Lureau" <marcandre.lureau@redhat.com>
Subject: Re: roms/efirom, tests/uefi-test-tools: update edk2's own submodules first
Date: Wed, 21 Oct 2020 19:27:35 +0200 [thread overview]
Message-ID: <d1641e6a-5af2-045b-5c4d-aa4512716f1d@redhat.com> (raw)
In-Reply-To: <20201021134634.GN412988@redhat.com>
On 10/21/20 15:46, Daniel P. Berrangé wrote:
> 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.
Can we implement the lightweight variant of this, namely extend
"pc-bios/README" to communicate this limitation? What you describe above
could be the very first paragraph (a file-top banner) in that file.
Also, it seems like "pc-bios/README" does not get installed under
$PREFIX/share/qemu. That looks like a general omission around
INSTALL_BLOBS / BLOBS to me. I can't remember -- was this the case
(i.e., "pc-bios/README" not getting installed) before the Meson
conversion too? (CC Paolo, Marc-André.)
Hm... even at the time of commit 26ce90fde5ce ("Makefile: install the
edk2 firmware images and their descriptors", 2019-04-17), BLOBS didn't
cover the "pc-bios/README" file.
Thanks,
Laszlo
next prev parent reply other threads:[~2020-10-21 17:28 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-20 9:16 roms/efirom, tests/uefi-test-tools: update edk2's own submodules first Olaf Hering
2020-10-20 9:29 ` Philippe Mathieu-Daudé
2020-10-20 9:35 ` Olaf Hering
2020-10-20 9:38 ` Philippe Mathieu-Daudé
2020-10-20 9:44 ` Daniel P. Berrangé
2020-10-20 9:54 ` Philippe Mathieu-Daudé
2020-10-21 12:05 ` Laszlo Ersek
2020-10-21 12:30 ` Olaf Hering
2020-10-21 13:28 ` Laszlo Ersek
2020-10-21 13:46 ` Daniel P. Berrangé
2020-10-21 17:27 ` Laszlo Ersek [this message]
2020-10-20 12:52 ` Olaf Hering
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d1641e6a-5af2-045b-5c4d-aa4512716f1d@redhat.com \
--to=lersek@redhat.com \
--cc=berrange@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=olaf@aepfle.de \
--cc=pbonzini@redhat.com \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).