BIOS shipped as binary blobs without source

Bug #541524 reported by Colin Watson on 2010-03-18
This bug affects 1 person
Affects Status Importance Assigned to Milestone
qemu-kvm (Ubuntu)
Dustin Kirkland 
Dustin Kirkland 

Bug Description

Binary package hint: qemu-kvm

<cjwatson> kirkland: ok, I'm lost now. What BIOS source are we actually using in kvm, where's its source, and why are there binary blobs in the qemu-kvm package?
<kirkland> cjwatson: well, we have seabios in the archive now, but upstream qemu strongly recommended that we use the bios they've blessed and released in 0.12.3
<cjwatson> kirkland: we need to ship source for it
<cjwatson> it's not OK to have sourceless binary blobs in main
<kirkland> cjwatson: we runtime-depended on seabios for a while, but it caused a few bugs that we couldn't reproduce against upstream
<kirkland> cjwatson: agreed, this is an oversight
<cjwatson> IMO we should be building it too, and making sure we get the same output from doing so
<kirkland> cjwatson: open a bug; i'm onsite at dell today/tomorrow, onsite at eucalyptus all of next week; i'll try to find some time
<cjwatson> ok
<kirkland> cjwatson:
<cjwatson> yep, saw that
<cjwatson> I understand the reasons, but we're wildly infringing our own policy here
<cjwatson> not to mention infringing copyright on the BIOSes, if this is LGPLed (it is, isn't it?)
<kirkland> cjwatson: i'm happy to revert that commit, and reopen
<ubottu> Ubuntu bug 513273 in qemu-kvm "kvm with -vga std is broken since karmic" [Low,Fix released]
<cjwatson> I'm not asking for us to use vgabios specifically
<kirkland> cjwatson: -vga std is low on my wishlist, fwiw
<cjwatson> the separate source package or whatever
<cjwatson> I'm entirely OK with it being shipped by qemu-kvm if that's considered appropriate, but not as binary blobs - we need to ship the matching source

Related branches

Colin Watson (cjwatson) on 2010-03-18
Changed in qemu-kvm (Ubuntu Lucid):
importance: Undecided → High
milestone: none → ubuntu-10.04-beta-2
Dustin Kirkland  (kirkland) wrote :

cjwatson> any binary blobs, yes
(need to be pruned or source provided).

 * bios.bin we can get from seabios (although there are known bugs with the version of seabios present in Lucid, but not in the upstream version of bios.bin)
 * vgabios we can get from vgabios (although there are known bugs with the version of seabios present in Lucid, but not in the upstream version of vgabios)
 * PXE roms we should get from kvm-pxe
 * OpenBIOS comes from, which is GPLv2, but not packaged for Ubuntu, see Bug #183495
 * video.x comes from, which is GPLv2, but not packaged for Ubuntu

So ideally, we need to:
 a) depend on seabios
 b) depend on vgabios
 c) package openbios, and depend on openbios
 d) package mol, and depend on mol

Packaging openbios and mol may not be reasonable for Lucid.

We have been discouraged by upstream QEMU to build/run different versions of any of these ROMs from what's shipped in the upstream tarball, as those versions are the ones that are known to work well.

As I said, it's fine to use versions that are shipped in the upstream
tarball; I certainly don't care whether the files live in the qemu-kvm
package or in vgabios etc. Regardless of this, though, we need to
provide source for them or we are infringing the licence on at least the
LGPLed BIOS ROMs. Upstream QEMU is not the copyright owner for all of
this stuff, as far as I can tell, and does not have the authority to
waive our obligations.

Aside from legal obligations, we're also skating along the edge of our
own licensing policy by not shipping source: One might point
out that BIOS ROMs are firmware and thus might be eligible for a
case-by-case exception. Such exceptions were only meant to be granted
when the only way we could get some piece of hardware working was to
ship some bit of firmware we only had in the form of a binary blob. I
don't think anyone ever envisaged that the reason we might be shipping
binary blobs would be because it was too hard to build from source
accurately, and this doesn't seem like a good basis for an exception.

I would strongly recommend building the ROMs from matching source code
(I don't think source is really source unless we're actually building
the binaries from it - part of the point of shipping source is so that
people can make modifications, and if the source doesn't verifiably
match what we're shipping then that rather defeats the point). If
you're concerned that it might not match, then perhaps you could simply
compare it against a checksum after building, with a comment saying that
this is to ensure that they match the versions that have been QAed by
upstream? I'd have thought that the sort of compilation being done here
is using fairly static toolchain elements and thus would produce fairly
static output, which would require at most minor massaging to become
bitwise-identical to what upstream's shipping.

On Thu, Mar 18, 2010 at 10:19:16PM -0000, Dustin Kirkland wrote:
> d) package mol, and depend on mol

video.x is already in the mol-drivers-macosx package (powerpc only); mol
has been in the Ubuntu archive since at least Hoary and I think since
the very beginning. It's not identical to the one in qemu-common,
although the two files are the same size.

mol-drivers-macosx is in multiverse, and in Debian it's in non-free.
This is because it is licensed under the AFPL 1.2, which forbids
"deploying" modified versions within an organisation without publishing
them, which is a restriction on privacy that we don't want in main. See for more discussion
here. Right now, qemu-kvm's copyright file doesn't mention the
copyright or licence for any of the BIOS ROMs, much less this problem.

Unless there's been an APSL 2 release of MOL, I don't think we can
legitimately include video.x in qemu-kvm, nor depend on

Changed in qemu-kvm (Ubuntu Lucid):
status: New → In Progress
assignee: nobody → Dustin Kirkland (kirkland)
Dustin Kirkland  (kirkland) wrote :


I re-rolled the orig tarball after removing the binary blobs, and called it qemu-kvm_0.12.3.noroms.orig.tar.gz. I set it (back to) depending on vgabios and seabios, and suggesting openbios-sparc and mol-drivers-macosx (neither of which have built in Ubuntu in a very long time).

I need to do a bit of testing on these.

What do you think?

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package qemu-kvm - 0.12.3+noroms-0ubuntu1

qemu-kvm (0.12.3+noroms-0ubuntu1) lucid; urgency=low

  * Re-roll the orig tarball, after having manually deleted the included
    binary-only bios rom blobs who source was not also included in the
    package, LP: #541524; the following files were removed:
    - pc-bios/bios.bin
    - pc-bios/linuxboot.bin
    - pc-bios/multiboot.bin
    - pc-bios/openbios-ppc
    - pc-bios/openbios-sparc
    - pc-bios/openbios-sparc32
    - pc-bios/openbios-sparc64
    - pc-bios/ppc_rom.bin
    - pc-bios/pxe-e1000.bin
    - pc-bios/pxe-i82559er.bin
    - pc-bios/pxe-ne2k_pci.bin
    - pc-bios/pxe-pcnet.bin
    - pc-bios/pxe-rtl8139.bin
    - pc-bios/pxe-virtio.bin
    - pc-bios/vapic.bin
    - pc-bios/vgabios.bin
    - pc-bios/vgabios-cirrus.bin
    - pc-bios/video.x
  * debian/control:
    - qemu-common goes back to depending on vgabios and seabios
    - suggest mol-drivers-macosx, which is in multiverse, and provides
      video.x (when that package actually builds)
    - suggest openbios-sparc, which is in universe, and provides the
      powerpc/sparc openbios roms (when that package actually builds)
  * debian/links:
    - put links in place for the external seabios and vgabios blobs
  * debian/patches/larger_default_ram_size.patch: increase the default
    mem size for virtual machines from the mostly unusable 128M to 384M,
    which most modern distros require
 -- Dustin Kirkland <email address hidden> Mon, 22 Mar 2010 18:14:30 -0700

Changed in qemu-kvm (Ubuntu Lucid):
status: In Progress → Fix Released
Id2ndR (id2ndr) wrote :

Actually this change is responsible of an new trouble with apparmor.

Extract of /var/log/syslog:
Mar 23 14:19:13 kiwi kernel: [ 7025.583776] type=1503 audit(1269350353.212:49): operation="open" pid=17840 parent=1 profile="libvirt-f25941b5-8a0b-086a-888e-fe8570f0487d" requested_mask="r::" denied_mask="r::" fsuid=0 ouid=0 name="/usr/share/seabios/bios.bin"
Mar 23 14:19:13 kiwi libvirtd: 14:19:13.401: error : qemudWaitForMonitor:1536 : internal error unable to start guest: char device redirected to /dev/pts/2#012qemu: could not load PC BIOS 'bios.bin'#012

Id2ndR (id2ndr) wrote :

see Bug #513273
provide right bios or -vga std do not work and this is important to provide resolution to vm

There are two different problems to be tackled here:

  - with seabios bios.bin we get a lot of messages saying "BUG: kvm_dirty_pages_log_enable_slot: invalid parameters".
  - with vgabios.bin and -vga std we get 800x600x4 maximum resolution, as a fallback in qemu.

I have tested different combinations of bios.bin and vgabios.bin, supplied by seabios and vgabios vs supplied by qemu sources, and have determined the two problems are completely independent. In fact, you get full vga resolution with seabios bios.bin and the qemu source's vgabios.bin, however the kvm_dirty_pages do appear.

*** As a workaround to the needy, delete the links bios.bin and vgabios.bin from /usr/share/qemu-kvm and copy the files with the same name from the directory pc-bios in qemu sources into the directory (or just copy vgabios.bin and use the -bios command line switch for qemu to select a bios.

Dustin Kirkland  (kirkland) wrote :

One issue per bug, guys ...

The -vga std problem is detailed in length in Bug #513273. Please continue the vga discussion there.

I just opened a new bug for the libvirt apparmor seabios issue, Bug #545302. Thanks for the patch, I'm rolling and uploading a fix just now.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers