Red Hat Bugzilla – Full Text Bug Listing
|Summary:||QEMU fails to start correctly via libvirt when seccomp/libseccomp sandboxing is enabled|
|Product:||[Fedora] Fedora||Reporter:||Paul Moore <pmoore>|
|Component:||qemu||Assignee:||Fedora Virtualization Maintainers <virt-maint>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||18||CC:||amit.shah, berrange, cfergeau, crobinso, dwmw2, eotubo, itamar, knoel, pbonzini, rjones, scottt.tw, virt-maint, yunzheng|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2013-01-14 19:48:43 EST||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Paul Moore 2012-09-06 16:41:36 EDT
Created attachment 610496 [details] QEMU seccomp/libseccomp patch (partial fix) Description of problem: When starting QEMU via libvirt with the seccomp/libseccomp sandboxing enabled it fails. Version-Release number of selected component (if applicable): >= Linux Kernel v 3.5 >= libseccomp v 1.0.0 >= QEMU v 1.2 How reproducible: Always Steps to Reproduce: 1. Add the '-sandbox on' QEMU command line to the libvirt domain (http://blog.vmsplice.net/2011/04/how-to-pass-qemu-command-line-options.html) 2. virsh start <domain> Actual results: The QEMU guest instance does not start correctly and libvirt complains about a state lock after some period of time.
Comment 1 Paul Moore 2012-09-06 16:42:48 EDT
It is important to note that the patch I just posted is not a complete fix, but I'm posting it here for reference. See the disclaimers in the patch description for more information.
Comment 3 Eduardo Otubo 2012-09-10 16:04:41 EDT
Created attachment 611560 [details] libvirt log for the test case Paul, I'm using the exact same environment: * Kernel 3.5.1-1.fc17.x86_64 * libseccomp 1.0.0 * QEMU 1.2 And I'm having the following results: Qemu1.2 unpatched: Error (attached file goes the libvirt log) Qemu1.2 patched : <defunct> process, don't start or crash The Fedora17 I'm using is a Qemu guest on my own computer, do you see any problems running the test in this "inception" scenario? My next step will be repatch my debug mode and find out if there's another missing syscall messing around. Thanks.
Comment 4 Paul Moore 2012-09-10 16:17:57 EDT
The patch, as mentioned in the description in this BZ, is not a full fix, just a partial fix for some known problems I saw on x86_64; I still see the same problems you described above but that was as far as I got last week. As we discussed offline, I didn't resume the investigation since you were looking into it. If this changes let me know and I'll start looking into it again.
Comment 5 Paolo Bonzini 2012-09-11 07:05:24 EDT
Things such as set_tid_address are internal to glibc, perhaps libseccomp could have a single way to add support for NPTL threads?
Comment 6 Paul Moore 2012-09-11 08:49:01 EDT
(In reply to comment #5) > Things such as set_tid_address are internal to glibc, perhaps libseccomp > could have a single way to add support for NPTL threads? There has been some talk of providing macros, or some other shorthand, to enable/disable specific classes of operations, however, I consider that relatively low in priority with respect to some of the other work that we are currently working on (multi/non-native arch, language bindings, etc.). If we do end up supporting the macro functionality described above, it makes sense that we would include a "thread management" macro.
Comment 7 Eduardo Otubo 2012-09-20 12:41:45 EDT
Created attachment 614984 [details] QEMU seccomp/libseccomp patch (final fix) This is the patch I believe fixes the bug. I run several tests on Fedora 17 both on x86_32 and x86_64 and they both did well. In the tests, the frequency they appear are always the same, only once or twice per instance, so I set frequency accordingly.
Comment 8 Paul Moore 2012-09-20 14:11:03 EDT
Great, glad to hear you've found the missing syscalls. I assume you'll be submitting the fix upstream?
Comment 9 Paul Moore 2012-09-26 16:03:52 EDT
Created attachment 617756 [details] F16 libvirt XML definition
Comment 10 Paul Moore 2012-09-26 16:05:35 EDT
Unfortunately this patch does not completely solve the problem for me when using F17/libvirt and the guest defined in attachment 617756 [details] (see above). The QEMU instance appears to start, and is reported as running, but I never see the BIOS POST on the console.
Comment 11 Eduardo Otubo 2012-11-29 10:43:47 EST
Created attachment 654374 [details] qemu patch This patch has been verified by Paul Moore and it fixes the bug reported above.
Comment 12 Paul Moore 2012-11-29 14:20:19 EST
Let's leave this at ASSIGNED until the patch is merged and we can verify a released QEMU package.
Comment 13 Paul Moore 2012-11-30 11:26:03 EST
A quick update: Anthony just applied Eduardo's patch so we should be in good shape for the QEMU 1.3 release. I'll revisit this to retest once we have a QEMU 1.3 packaged.
Comment 14 Paul Moore 2012-11-30 12:02:19 EST
Also, along with this patch and/or QEMU release we should also bump the libseccomp dependency from 1.0.0 to 1.0.1.
Comment 15 Fedora Update System 2012-12-16 20:26:31 EST
qemu-1.2.2-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/qemu-1.2.2-1.fc18
Comment 16 Fedora Update System 2013-01-11 18:54:44 EST
qemu-1.2.2-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.