Bug 855162 - QEMU fails to start correctly via libvirt when seccomp/libseccomp sandboxing is enabled
Summary: QEMU fails to start correctly via libvirt when seccomp/libseccomp sandboxing ...
Alias: None
Product: Fedora
Classification: Fedora
Component: qemu
Version: 18
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Fedora Virtualization Maintainers
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2012-09-06 20:41 UTC by Paul Moore
Modified: 2013-01-15 00:48 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-01-15 00:48:43 UTC
Type: Bug

Attachments (Terms of Use)
QEMU seccomp/libseccomp patch (partial fix) (1.48 KB, patch)
2012-09-06 20:41 UTC, Paul Moore
no flags Details | Diff
libvirt log for the test case (1.09 KB, text/plain)
2012-09-10 20:04 UTC, Eduardo Otubo
no flags Details
QEMU seccomp/libseccomp patch (final fix) (1.28 KB, patch)
2012-09-20 16:41 UTC, Eduardo Otubo
no flags Details | Diff
F16 libvirt XML definition (2.30 KB, application/xml)
2012-09-26 20:03 UTC, Paul Moore
no flags Details
qemu patch (8.18 KB, patch)
2012-11-29 15:43 UTC, Eduardo Otubo
no flags Details | Diff

Description Paul Moore 2012-09-06 20:41:36 UTC
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:

Steps to Reproduce:
1. Add the '-sandbox on' QEMU command line to the libvirt domain
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 20:42:48 UTC
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 20:04:41 UTC
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.


Comment 4 Paul Moore 2012-09-10 20:17:57 UTC
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 11:05:24 UTC
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 12:49:01 UTC
(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 16:41:45 UTC
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 18:11:03 UTC
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 20:03:52 UTC
Created attachment 617756 [details]
F16 libvirt XML definition

Comment 10 Paul Moore 2012-09-26 20:05:35 UTC
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 15:43:47 UTC
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 19:20:19 UTC
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 16:26:03 UTC
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 17:02:19 UTC
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-17 01:26:31 UTC
qemu-1.2.2-1.fc18 has been submitted as an update for Fedora 18.

Comment 16 Fedora Update System 2013-01-11 23:54:44 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.