[Bug 830002] New: QEMU firmware not built from source
https://bugzilla.novell.com/show_bug.cgi?id=830002 https://bugzilla.novell.com/show_bug.cgi?id=830002#c0 Summary: QEMU firmware not built from source Classification: openSUSE Product: openSUSE Factory Version: 13.1 Milestone 3 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: KVM AssignedTo: boyang@suse.com ReportedBy: brogers@suse.com QAContact: jdouglas@suse.com Found By: --- Blocker: --- Though there is a certain degree of trust in the firmware components provided in the upstream QEMU project, effort should be made to build that firmware from source, especially in the cases where it is readily known how to do so. At the risk of stating the obvious, when binary blobs are used, there is an insufficient audit trail from source code to executable. In the case of virtual machine firmware, where it executes with nearly complete ownership of the vm execution environment, the ability to prove that there are no security holes or malicious code present is even more important than for "normal software". Since we use a build service which allows leveraging various cpu architectures to be build on, we should use it to the full extent to build the firmware we use. If there is firmware needed for emulated architectures which can not be reasonably built for, including with cross-architecture development tools, we should at least identify clearly the source code used to build that firmware, and provide it, even if we have to trust that it was built correctly elsewhere. url on openSUSE policies for open source software: http://en.opensuse.org/Free_and_Open_Source_Software I can point out that an effort to correct this issue has been started. See: qemu, kvm, and virt-firmware packages in home:bfrogers in the openSUSE build service. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=830002 https://bugzilla.novell.com/show_bug.cgi?id=830002#c Yang Bo <boyang@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=830002 https://bugzilla.novell.com/show_bug.cgi?id=830002#c1 --- Comment #1 from Yang Bo <boyang@suse.com> 2013-07-19 09:59:27 UTC --- already splitted bios/pxe from kvm package. needs decoration on package description. An the work is based on 1.3.0. may need to adjust some directory for 1.5. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=830002 https://bugzilla.novell.com/show_bug.cgi?id=830002#c2 --- Comment #2 from Bruce Rogers <brogers@suse.com> 2013-07-31 22:15:40 UTC --- Just an update - As I was hoping to get something checked in for M4 of openSUSE 13.1, I now want to take a less hurried approach here, as it seems that there are many factors that need to be worked through to make sure we are doing this the right way. Some concerns are: * What is the best way to ensure we are tracking correctly the firmware versions needed by QEMU (and possibly Xen) * What granularity should be used to provide firmware - one package for all firmware, or one package per tar-ball, etc * for firmware which we can not yet build (and perhaps never will be able to build), what package should deliver that component * It's not really clear what the best way to build firmware for other arch's is. The noarch package with per-arch processing seems to work ok, but if we end up needing in the long run to either do cross compilation, or possibly user-mode emulation to get full coverage of building all firmware components used, then perhaps we'd want to look into consolidating around that solutions from the get go. * Do we draw a line in the sand for some of the much less used target archs (and for which we don't have support in the build service) and just live with not building the firmware for those archs? * It is still unclear if we can correctly identify all the sources needed to build the same firmware as what is provided in the upstream provided binary blobs I'd like to have more of these questions answered before we commit to a specific approach. Let's work towards the openSUSE 13.1 Beta to have the critical issues resolved and to have a solid plan in place for the rest. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=830002 https://bugzilla.novell.com/show_bug.cgi?id=830002#c3 Bruce Rogers <brogers@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|boyang@suse.com |brogers@suse.com --- Comment #3 from Bruce Rogers <brogers@suse.com> 2013-09-16 16:17:36 UTC --- We now have checked in, for the openSUSE 13.1 beta, 4 firmware packages, which cover the major use case. This brings us back to what we previously had been building from source within the kvm package: seabios, vgabios, sgabios, and ipxe. These are packaged with a qemu- prefix, from within the x86 qemu package, using the sources that come in the qemu tarball as well as a tweaked roms/Makefile, which is also provided upstream. These are noarch packages. For non-x86 architectures these packages are also provided, but in this case the packages simply contain repackaged upstream firmware binary blobs. As mentioned above, this basically gets us back to a previous level of building from firmware. More of course needs to be done to fully resolve this bug. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com