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

[Anthony Liguori <anthony@codemonkey.ws>]

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/kvm@vger.kernel.org/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.
>
>