Bug 855162 - QEMU fails to start correctly via libvirt when seccomp/libseccomp sandboxing is enabled
QEMU fails to start correctly via libvirt when seccomp/libseccomp sandboxing ...
Product: Fedora
Classification: Fedora
Component: qemu (Show other bugs)
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Fedora Virtualization Maintainers
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2012-09-06 16:41 EDT by Paul Moore
Modified: 2013-01-14 19:48 EST (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-01-14 19:48:43 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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

  None (edit)
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:

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 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


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 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.
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.

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