qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Laszlo Ersek
Subject: Re: roms/efirom, tests/uefi-test-tools: update edk2's own submodules first
Date: Wed, 21 Oct 2020 19:27:35 +0200

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]