qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Re: pc-bios/bios.bin - where it comes from?


From: Anthony Liguori
Subject: Re: [Qemu-devel] Re: pc-bios/bios.bin - where it comes from?
Date: Fri, 05 Mar 2010 07:51:50 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Lightning/1.0pre Thunderbird/3.0

On 03/05/2010 07:39 AM, Aurelien Jarno wrote:
Anthony Liguori a écrit :
On 03/04/2010 04:46 PM, Michael Tokarev wrote:
Hello.

There are a few bugs filed about an.. interesting
behavour.  For example:

   http://www.mail-archive.com/address@hidden/msg29834.html
   https://bugs.launchpad.net/qemu/+bug/513273

After quite some mix-n-matching, at least on my test machine,
I can say that the issue gets triggered by seabios.  When
using pc-bios/bios.bin everything is ok.  But when using
any other bios.bin, even downloading seabios-0.5.1.tar.gz
and building it - on a debian lenny system anyway - by
running `make', the problem triggers.

I tried different versions/variations of vgabios.bin
(it's only -vga std which triggers the issue so far),
including 0.6b and 0.6c built from sources, vgabios.bin
from debian packages (0.6b and 0.6c), and the one
included in qemu-0.12.3.tar.gz.  And my conclusion
so far is that vgabios.bin has exactly _no_ effect on
the issue.

But when using bios.bin from qemu-kvm-0.12.3.tar.gz,
and _only_ that bios.bin, the problem goes away.

pc-bios/bios.bin gets built from roms/seabios.

We don't ship seabios 0.5.1 in 0.12.3, we ship 0.5.1-stable which is two
commits ahead of 0.5.1.

So the question arises: where that pc-bios/bios.bin
comes from into qemu-0.12.3.tar.gz?  It is either
built from some other sources (not from seabios-0.5.1),
or built with some extra/different compiler/linker options,
or built using different compiler/linker.

This is partially confirmed on ubuntu as well, but,
as far as I understand, there the behavour is different
with different versions of vgabios.

One of the reasons we include a git submodule and the source for the
bios is so that distributors don't have to deal with building the
packages independently.  Morale of the story is, just use the source we
ship and don't try to be more clever than that :-)

This is exactly what distribution usually fight about: same code in
different packages, but with subtle differences. If every software was
like that, we would not have shared libraries anymore. This is a
nightmare at different levels, and especially at security level.

We should probably interact more with the maintainers of the various
BIOS package (that could mean synced release),

We currently do this with SeaBIOS. But ultimately, x86 firmware is tied very closely to the underlying hardware.

Keep in mind, this is software that runs within a guest, not in the host environment. It's really more of a data file than anything else. It cannot be the source of a CVE.

Regards,

Anthony Liguori


  in order to avoid this
kind of problem. Of course it doesn't mean we should not provide the
BIOS sources in QEMU.






reply via email to

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