[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH for-1.7] seccomp: setting "-sandbox on" by defau
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-devel] [PATCH for-1.7] seccomp: setting "-sandbox on" by default |
Date: |
Thu, 5 Dec 2013 14:15:01 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Wed, Dec 04, 2013 at 11:21:12AM -0200, Eduardo Otubo wrote:
> On 12/04/2013 07:39 AM, Stefan Hajnoczi wrote:
> >On Fri, Nov 22, 2013 at 11:00:24AM -0500, Paul Moore wrote:
> >>>Developers will only be happy with seccomp if it's easy and rewarding to
> >>>support/debug.
> >>
> >>Agreed.
> >>
> >>As a developer, how do you feel about the audit/syslog based approach I
> >>mentioned earlier?
> >
> >I used the commands you posted (I think that's what you mean). They
> >produce useful output.
> >
> >The problem is that without an error message on stderr or from the
> >shell, no one will think "QEMU process dead and hung == check seccomp"
> >immediately. It's frustrating to deal with a "silent" failure.
>
> The process dies with a SIGKILL, and sig handling in Qemu is hard to
> implement due to dozen of external linked libraries that has their
> own signal masks and conflicts with seccomp. I've already tried this
> approach in the past (you can find in the list by searching for
> debug mode)
I now realize we may be talking past each other. Dying with
SIGKILL/SIGSYS is perfectly reasonable and I would be happy with that
:-).
But I think there's a bug in seccomp: a multi-threaded process can be
left in a zombie state. In my case the primary thread was killed by
seccomp but another thread was deadlocked on a futex.
The result is the process isn't quite dead yet. The shell will not reap
it and we're stuck with a zombie.
I can reproduce it reliably when I run "qemu-system-x86_64 -sandbox on"
on Fedora 20 (qemu-system-x86-1.6.1-2).
Should seccomp use do_group_exit() for SIGKILL?
Stefan