Red Hat Bugzilla – Bug 855162
QEMU fails to start correctly via libvirt when seccomp/libseccomp sandboxing is enabled
Last modified: 2013-01-14 19:48:43 EST
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
Steps to Reproduce:
1. Add the '-sandbox on' QEMU command line to the libvirt domain
2. virsh start <domain>
The QEMU guest instance does not start correctly and libvirt complains about a state lock after some period of time.
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.
Created attachment 611560 [details]
libvirt log for the test case
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.
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.
Things such as set_tid_address are internal to glibc, perhaps libseccomp could have a single way to add support for NPTL threads?
(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.
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.
Great, glad to hear you've found the missing syscalls. I assume you'll be submitting the fix upstream?
Created attachment 617756 [details]
F16 libvirt XML definition
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.
Created attachment 654374 [details]
This patch has been verified by Paul Moore and it fixes the bug reported above.
Let's leave this at ASSIGNED until the patch is merged and we can verify a released QEMU package.
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.
Also, along with this patch and/or QEMU release we should also bump the libseccomp dependency from 1.0.0 to 1.0.1.
qemu-1.2.2-1.fc18 has been submitted as an update for Fedora 18.
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.