Patchwork [PATCHv3,1/5] seccomp: adding new syscalls (bugzilla 855162)

login
register
mail settings
Submitter Eduardo Otubo
Date Nov. 12, 2012, 7:48 p.m.
Message ID <1352749698-1219-1-git-send-email-otubo@linux.vnet.ibm.com>
Download mbox | patch
Permalink /patch/198456/
State New
Headers show

Comments

Eduardo Otubo - Nov. 12, 2012, 7:48 p.m.
According to the bug 855162[0] - there's the need of adding new syscalls
to the whitelist when using Qemu with Libvirt.

[0] - https://bugzilla.redhat.com/show_bug.cgi?id=855162

v2: Adding new syscalls to the list: readlink, rt_sigpending, and
    rt_sigtimedwait

v3:
 * Added new syscalls based on further tests.
 * Added new syscalls with priority 241 that are unknown to be
   used by QEMU.  We'll attempt to remove these after QEMU 1.3.

Reported-by: Paul Moore <pmoore@redhat.com>
Signed-off-by: Eduardo Otubo <otubo@linux.vnet.ibm.com>
Signed-off-by: Corey Bryant <coreyb@linux.vnet.ibm.com>
---
 qemu-seccomp.c |  148 +++++++++++++++++++++++++++++++++++++++++++++++++-------
 1 file changed, 131 insertions(+), 17 deletions(-)
Eduardo Otubo - Nov. 21, 2012, 1:20 p.m.
Hello folks, 

Does anyone had a chance to take a look at this? We would like to get
this into the 1.3 release.

Thanks again :)

On Mon, Nov 12, 2012 at 05:48:14PM -0200, Eduardo Otubo wrote:
> According to the bug 855162[0] - there's the need of adding new syscalls
> to the whitelist when using Qemu with Libvirt.
> 
> [0] - https://bugzilla.redhat.com/show_bug.cgi?id=855162
> 
> v2: Adding new syscalls to the list: readlink, rt_sigpending, and
>     rt_sigtimedwait
> 
> v3:
>  * Added new syscalls based on further tests.
>  * Added new syscalls with priority 241 that are unknown to be
>    used by QEMU.  We'll attempt to remove these after QEMU 1.3.
> 
> Reported-by: Paul Moore <pmoore@redhat.com>
> Signed-off-by: Eduardo Otubo <otubo@linux.vnet.ibm.com>
> Signed-off-by: Corey Bryant <coreyb@linux.vnet.ibm.com>
> ---
>  qemu-seccomp.c |  148 +++++++++++++++++++++++++++++++++++++++++++++++++-------
>  1 file changed, 131 insertions(+), 17 deletions(-)
> 
> diff --git a/qemu-seccomp.c b/qemu-seccomp.c
> index 64329a3..b06a2c6 100644
> --- a/qemu-seccomp.c
> +++ b/qemu-seccomp.c
> @@ -26,8 +26,12 @@ static const struct QemuSeccompSyscall seccomp_whitelist[] = {
>      { SCMP_SYS(timer_gettime), 254 },
>      { SCMP_SYS(futex), 253 },
>      { SCMP_SYS(select), 252 },
> +#if defined(__x86_64__)
>      { SCMP_SYS(recvfrom), 251 },
>      { SCMP_SYS(sendto), 250 },
> +#elif defined(__i386__)
> +    { SCMP_SYS(socketcall), 250 },
> +#endif
>      { SCMP_SYS(read), 249 },
>      { SCMP_SYS(brk), 248 },
>      { SCMP_SYS(clone), 247 },
> @@ -36,15 +40,30 @@ static const struct QemuSeccompSyscall seccomp_whitelist[] = {
>      { SCMP_SYS(execve), 245 },
>      { SCMP_SYS(open), 245 },
>      { SCMP_SYS(ioctl), 245 },
> +#if defined(__x86_64__)
> +    { SCMP_SYS(socket), 245 },
> +    { SCMP_SYS(setsockopt), 245 },
>      { SCMP_SYS(recvmsg), 245 },
>      { SCMP_SYS(sendmsg), 245 },
>      { SCMP_SYS(accept), 245 },
>      { SCMP_SYS(connect), 245 },
> +    { SCMP_SYS(socketpair), 245 },
> +    { SCMP_SYS(bind), 245 },
> +    { SCMP_SYS(listen), 245 },
> +    { SCMP_SYS(semget), 245 },
> +#elif defined(__i386__)
> +    { SCMP_SYS(ipc), 245 },
> +#endif
>      { SCMP_SYS(gettimeofday), 245 },
>      { SCMP_SYS(readlink), 245 },
>      { SCMP_SYS(access), 245 },
>      { SCMP_SYS(prctl), 245 },
>      { SCMP_SYS(signalfd), 245 },
> +    { SCMP_SYS(getrlimit), 245 },
> +    { SCMP_SYS(set_tid_address), 245 },
> +    { SCMP_SYS(statfs), 245 },
> +    { SCMP_SYS(unlink), 245 },
> +    { SCMP_SYS(wait4), 245 },
>  #if defined(__i386__)
>      { SCMP_SYS(fcntl64), 245 },
>      { SCMP_SYS(fstat64), 245 },
> @@ -56,24 +75,26 @@ static const struct QemuSeccompSyscall seccomp_whitelist[] = {
>      { SCMP_SYS(sigreturn), 245 },
>      { SCMP_SYS(_newselect), 245 },
>      { SCMP_SYS(_llseek), 245 },
> -    { SCMP_SYS(mmap2), 245},
> +    { SCMP_SYS(mmap2), 245 },
>      { SCMP_SYS(sigprocmask), 245 },
> -#elif defined(__x86_64__)
> -    { SCMP_SYS(sched_getparam), 245},
> -    { SCMP_SYS(sched_getscheduler), 245},
> -    { SCMP_SYS(fstat), 245},
> -    { SCMP_SYS(clock_getres), 245},
> -    { SCMP_SYS(sched_get_priority_min), 245},
> -    { SCMP_SYS(sched_get_priority_max), 245},
> -    { SCMP_SYS(stat), 245},
> -    { SCMP_SYS(socket), 245},
> -    { SCMP_SYS(setsockopt), 245},
> -    { SCMP_SYS(uname), 245},
> -    { SCMP_SYS(semget), 245},
>  #endif
> +    { SCMP_SYS(sched_getparam), 245 },
> +    { SCMP_SYS(sched_getscheduler), 245 },
> +    { SCMP_SYS(fstat), 245 },
> +    { SCMP_SYS(clock_getres), 245 },
> +    { SCMP_SYS(sched_get_priority_min), 245 },
> +    { SCMP_SYS(sched_get_priority_max), 245 },
> +    { SCMP_SYS(stat), 245 },
> +    { SCMP_SYS(uname), 245 },
>      { SCMP_SYS(eventfd2), 245 },
>      { SCMP_SYS(dup), 245 },
> +    { SCMP_SYS(dup2), 245 },
> +    { SCMP_SYS(dup3), 245 },
>      { SCMP_SYS(gettid), 245 },
> +    { SCMP_SYS(getgid), 245 },
> +    { SCMP_SYS(getegid), 245 },
> +    { SCMP_SYS(getuid), 245 },
> +    { SCMP_SYS(geteuid), 245 },
>      { SCMP_SYS(timer_create), 245 },
>      { SCMP_SYS(exit), 245 },
>      { SCMP_SYS(clock_gettime), 245 },
> @@ -93,8 +114,6 @@ static const struct QemuSeccompSyscall seccomp_whitelist[] = {
>      { SCMP_SYS(lseek), 245 },
>      { SCMP_SYS(pselect6), 245 },
>      { SCMP_SYS(fork), 245 },
> -    { SCMP_SYS(bind), 245 },
> -    { SCMP_SYS(listen), 245 },
>      { SCMP_SYS(eventfd), 245 },
>      { SCMP_SYS(rt_sigprocmask), 245 },
>      { SCMP_SYS(write), 244 },
> @@ -104,10 +123,105 @@ static const struct QemuSeccompSyscall seccomp_whitelist[] = {
>      { SCMP_SYS(pipe2), 242 },
>      { SCMP_SYS(munmap), 242 },
>      { SCMP_SYS(mremap), 242 },
> +    { SCMP_SYS(fdatasync), 242 },
> +    { SCMP_SYS(close), 242 },
> +    { SCMP_SYS(rt_sigpending), 242 },
> +    { SCMP_SYS(rt_sigtimedwait), 242 },
> +    { SCMP_SYS(readv), 242 },
> +    { SCMP_SYS(writev), 242 },
> +    { SCMP_SYS(preadv), 242 },
> +    { SCMP_SYS(pwritev), 242 },
> +    { SCMP_SYS(setrlimit), 242 },
> +    { SCMP_SYS(ftruncate), 242 },
> +    { SCMP_SYS(lstat), 242 },
> +    { SCMP_SYS(pipe), 242 },
> +    { SCMP_SYS(umask), 242 },
> +    { SCMP_SYS(chdir), 242 },
> +    { SCMP_SYS(setitimer), 242 },
> +    { SCMP_SYS(setsid), 242 },
> +    { SCMP_SYS(poll), 242 },
> +#if defined(__i386__)
> +    { SCMP_SYS(waitpid), 242 },
> +#elif defined(__x86_64__)
>      { SCMP_SYS(getsockname), 242 },
>      { SCMP_SYS(getpeername), 242 },
> -    { SCMP_SYS(fdatasync), 242 },
> -    { SCMP_SYS(close), 242 }
> +    { SCMP_SYS(accept4), 242 },
> +    { SCMP_SYS(newfstatat), 241 },
> +    { SCMP_SYS(shutdown), 241 },
> +    { SCMP_SYS(getsockopt), 241 },
> +    { SCMP_SYS(semctl), 241 },
> +    { SCMP_SYS(semop), 241 },
> +    { SCMP_SYS(semtimedop), 241 },
> +#endif
> +    { SCMP_SYS(ppoll), 241 },
> +    { SCMP_SYS(creat), 241 },
> +    { SCMP_SYS(link), 241 },
> +    { SCMP_SYS(getpid), 241 },
> +    { SCMP_SYS(getppid), 241 },
> +    { SCMP_SYS(getpgrp), 241 },
> +    { SCMP_SYS(getpgid), 241 },
> +    { SCMP_SYS(getsid), 241 },
> +    { SCMP_SYS(getdents64), 241 },
> +    { SCMP_SYS(getresuid), 241 },
> +    { SCMP_SYS(getresgid), 241 },
> +    { SCMP_SYS(getgroups), 241 },
> +#if defined(__i386__)
> +    { SCMP_SYS(getresuid32), 241 },
> +    { SCMP_SYS(getresgid32), 241 },
> +    { SCMP_SYS(getgroups32), 241 },
> +    { SCMP_SYS(signal), 241 },
> +    { SCMP_SYS(sigaction), 241 },
> +    { SCMP_SYS(sigsuspend), 241 },
> +    { SCMP_SYS(sigpending), 241 },
> +    { SCMP_SYS(truncate64), 241 },
> +    { SCMP_SYS(ftruncate64), 241 },
> +    { SCMP_SYS(fchown32), 241 },
> +    { SCMP_SYS(chown32), 241 },
> +    { SCMP_SYS(lchown32), 241 },
> +    { SCMP_SYS(statfs64), 241 },
> +    { SCMP_SYS(fstatfs64), 241 },
> +    { SCMP_SYS(fstatat64), 241 },
> +    { SCMP_SYS(lstat64), 241 },
> +    { SCMP_SYS(sendfile64), 241 },
> +    { SCMP_SYS(ugetrlimit), 241 },
> +#endif
> +    { SCMP_SYS(alarm), 241 },
> +    { SCMP_SYS(rt_sigsuspend), 241 },
> +    { SCMP_SYS(rt_sigqueueinfo), 241 },
> +    { SCMP_SYS(rt_tgsigqueueinfo), 241 },
> +    { SCMP_SYS(sigaltstack), 241 },
> +    { SCMP_SYS(signalfd4), 241 },
> +    { SCMP_SYS(truncate), 241 },
> +    { SCMP_SYS(fchown), 241 },
> +    { SCMP_SYS(lchown), 241 },
> +    { SCMP_SYS(fchownat), 241 },
> +    { SCMP_SYS(fstatfs), 241 },
> +    { SCMP_SYS(sendfile), 241 },
> +    { SCMP_SYS(getitimer), 241 },
> +    { SCMP_SYS(syncfs), 241 },
> +    { SCMP_SYS(fsync), 241 },
> +    { SCMP_SYS(fchdir), 241 },
> +    { SCMP_SYS(flock), 241 },
> +    { SCMP_SYS(msync), 241 },
> +    { SCMP_SYS(sched_setparam), 241 },
> +    { SCMP_SYS(sched_setscheduler), 241 },
> +    { SCMP_SYS(sched_yield), 241 },
> +    { SCMP_SYS(sched_rr_get_interval), 241 },
> +    { SCMP_SYS(sched_setaffinity), 241 },
> +    { SCMP_SYS(sched_getaffinity), 241 },
> +    { SCMP_SYS(readahead), 241 },
> +    { SCMP_SYS(timer_getoverrun), 241 },
> +    { SCMP_SYS(unlinkat), 241 },
> +    { SCMP_SYS(readlinkat), 241 },
> +    { SCMP_SYS(faccessat), 241 },
> +    { SCMP_SYS(get_robust_list), 241 },
> +    { SCMP_SYS(splice), 241 },
> +    { SCMP_SYS(vmsplice), 241 },
> +    { SCMP_SYS(getcpu), 241 },
> +    { SCMP_SYS(sendmmsg), 241 },
> +    { SCMP_SYS(recvmmsg), 241 },
> +    { SCMP_SYS(prlimit64), 241 },
> +    { SCMP_SYS(waitid), 241 }
>  };
> 
>  int seccomp_start(void)
> -- 
> 1.7.10.4
>
Paul Moore - Nov. 21, 2012, 3:24 p.m.
On Wednesday, November 21, 2012 11:20:44 AM Eduardo Otubo wrote:
> Hello folks,
> 
> Does anyone had a chance to take a look at this? We would like to get
> this into the 1.3 release.
> 
> Thanks again :)

I way a bit delayed due to travel, but I started playing with it a bit 
yesterday afternoon and unfortunately it still doesn't work for me (using the 
same test/reproducer I documented in the RH BZ).  I've tried running QEMU both 
via libvirt and the command line (using a libvirt derived command line).

I'm applying the patches to the F17 QEMU 1.2 package; there is some minor 
fixup needed in the configure script but nothing major.

What is further frustrating is that the debug code (patch 5/5) doesn't seem to 
output the problematic syscall.  I wanted to investigate this a bit more 
before responding, but with the holiday approaching (Thanksgiving in the US), 
I'm not sure how much progress I'll be able to make for the remainder of this 
week.  Sorry about that.

If you have any further questions about how, or what, I'm testing, just ask.
Andreas Färber - Nov. 21, 2012, 3:30 p.m.
Hello,

Am 21.11.2012 14:20, schrieb Eduardo Otubo:
> Does anyone had a chance to take a look at this? We would like to get
> this into the 1.3 release.

We're in Hard Freeze, so in theory only bug fixes will get accepted for
v1.3. Patches intended for 1.3 should be marked "for-1.3" during this
period.

Some formal comments: Please supply a minimal cover letter for a patch
series to aid threaded display. We have been asked to not include patch
versioning in the commit message (which gets committed) but in the cover
letter or hidden below the --- line of the patches.

Regards,
Andreas
Corey Bryant - Nov. 26, 2012, 4:41 p.m.
On 11/21/2012 10:24 AM, Paul Moore wrote:
> On Wednesday, November 21, 2012 11:20:44 AM Eduardo Otubo wrote:
>> Hello folks,
>>
>> Does anyone had a chance to take a look at this? We would like to get
>> this into the 1.3 release.
>>
>> Thanks again :)
>
> I way a bit delayed due to travel, but I started playing with it a bit
> yesterday afternoon and unfortunately it still doesn't work for me (using the
> same test/reproducer I documented in the RH BZ).  I've tried running QEMU both
> via libvirt and the command line (using a libvirt derived command line).
>
> I'm applying the patches to the F17 QEMU 1.2 package; there is some minor
> fixup needed in the configure script but nothing major.
>
> What is further frustrating is that the debug code (patch 5/5) doesn't seem to
> output the problematic syscall.  I wanted to investigate this a bit more
> before responding, but with the holiday approaching (Thanksgiving in the US),
> I'm not sure how much progress I'll be able to make for the remainder of this
> week.  Sorry about that.
>
> If you have any further questions about how, or what, I'm testing, just ask.
>

Paul, Is your host 32 or 64-bit?
Paul Moore - Nov. 26, 2012, 5:08 p.m.
On Monday, November 26, 2012 11:41:06 AM Corey Bryant wrote:
> On 11/21/2012 10:24 AM, Paul Moore wrote:
> > On Wednesday, November 21, 2012 11:20:44 AM Eduardo Otubo wrote:
> >> Hello folks,
> >> 
> >> Does anyone had a chance to take a look at this? We would like to get
> >> this into the 1.3 release.
> >> 
> >> Thanks again :)
> > 
> > I way a bit delayed due to travel, but I started playing with it a bit
> > yesterday afternoon and unfortunately it still doesn't work for me (using
> > the same test/reproducer I documented in the RH BZ).  I've tried running
> > QEMU both via libvirt and the command line (using a libvirt derived
> > command line).
> > 
> > I'm applying the patches to the F17 QEMU 1.2 package; there is some minor
> > fixup needed in the configure script but nothing major.
> > 
> > What is further frustrating is that the debug code (patch 5/5) doesn't
> > seem to output the problematic syscall.  I wanted to investigate this a
> > bit more before responding, but with the holiday approaching
> > (Thanksgiving in the US), I'm not sure how much progress I'll be able to
> > make for the remainder of this week.  Sorry about that.
> > 
> > If you have any further questions about how, or what, I'm testing, just
> > ask.
>
> Paul, Is your host 32 or 64-bit?

64-bit
Corey Bryant - Nov. 26, 2012, 7:59 p.m.
On 11/26/2012 12:08 PM, Paul Moore wrote:
> On Monday, November 26, 2012 11:41:06 AM Corey Bryant wrote:
>> On 11/21/2012 10:24 AM, Paul Moore wrote:
>>> On Wednesday, November 21, 2012 11:20:44 AM Eduardo Otubo wrote:
>>>> Hello folks,
>>>>
>>>> Does anyone had a chance to take a look at this? We would like to get
>>>> this into the 1.3 release.
>>>>
>>>> Thanks again :)
>>>
>>> I way a bit delayed due to travel, but I started playing with it a bit
>>> yesterday afternoon and unfortunately it still doesn't work for me (using
>>> the same test/reproducer I documented in the RH BZ).  I've tried running
>>> QEMU both via libvirt and the command line (using a libvirt derived
>>> command line).
>>>
>>> I'm applying the patches to the F17 QEMU 1.2 package; there is some minor
>>> fixup needed in the configure script but nothing major.
>>>
>>> What is further frustrating is that the debug code (patch 5/5) doesn't
>>> seem to output the problematic syscall.  I wanted to investigate this a
>>> bit more before responding, but with the holiday approaching
>>> (Thanksgiving in the US), I'm not sure how much progress I'll be able to
>>> make for the remainder of this week.  Sorry about that.
>>>
>>> If you have any further questions about how, or what, I'm testing, just
>>> ask.
>>
>> Paul, Is your host 32 or 64-bit?
>
> 64-bit
>

I'm having trouble recreating this.  I'm running a Fedora 17 64-bit host 
and a Fedora 17 64-bit guest with domain XML that mirrors yours.

Here's the domain XML I'm using and the resulting QEMU command line:

Domain XML:   http://pastebin.com/DWa4RQ1Y
Command line: http://pastebin.com/2QTWsUhP

I'm running with QEMU commit 8db972cfa469b4e4afd9c65e54e796b83b5ce3a2 
which is 1.2.0 with: (a) just the first patch applied, as well as with 
(b) all of this patch series applied.

Any thoughts on what could be different?
Paul Moore - Nov. 26, 2012, 8:41 p.m.
On Monday, November 26, 2012 02:59:21 PM Corey Bryant wrote:
> On 11/26/2012 12:08 PM, Paul Moore wrote:
> > On Monday, November 26, 2012 11:41:06 AM Corey Bryant wrote:
> >> On 11/21/2012 10:24 AM, Paul Moore wrote:
> >>> On Wednesday, November 21, 2012 11:20:44 AM Eduardo Otubo wrote:
> >>>> Hello folks,
> >>>> 
> >>>> Does anyone had a chance to take a look at this? We would like to get
> >>>> this into the 1.3 release.
> >>>> 
> >>>> Thanks again :)
> >>> 
> >>> I way a bit delayed due to travel, but I started playing with it a bit
> >>> yesterday afternoon and unfortunately it still doesn't work for me
> >>> (using the same test/reproducer I documented in the RH BZ).  I've tried
> >>> running QEMU both via libvirt and the command line (using a libvirt
> >>> derived command line).
> >>> 
> >>> I'm applying the patches to the F17 QEMU 1.2 package; there is some
> >>> minor fixup needed in the configure script but nothing major.
> >>> 
> >>> What is further frustrating is that the debug code (patch 5/5) doesn't
> >>> seem to output the problematic syscall.  I wanted to investigate this a
> >>> bit more before responding, but with the holiday approaching
> >>> (Thanksgiving in the US), I'm not sure how much progress I'll be able to
> >>> make for the remainder of this week.  Sorry about that.
> >>> 
> >>> If you have any further questions about how, or what, I'm testing, just
> >>> ask.
> >> 
> >> Paul, Is your host 32 or 64-bit?
> > 
> > 64-bit
> 
> I'm having trouble recreating this.  I'm running a Fedora 17 64-bit host
> and a Fedora 17 64-bit guest with domain XML that mirrors yours.
> 
> Here's the domain XML I'm using and the resulting QEMU command line:
> 
> Domain XML:   http://pastebin.com/DWa4RQ1Y
> Command line: http://pastebin.com/2QTWsUhP
> 
> I'm running with QEMU commit 8db972cfa469b4e4afd9c65e54e796b83b5ce3a2
> which is 1.2.0 with: (a) just the first patch applied, as well as with
> (b) all of this patch series applied.
> 
> Any thoughts on what could be different?

Like I said earlier, I'm running with the F17 QEMU 1.2 package, 
qemu-1.2.0-16.fc18 to be exact, with Eduardo's patches applied on top.

I'm currently testing another set of interim patches from Eduardo that was 
sent off-list for testing (you were CC'd); hopefully that will resolve the 
problem.
Paul Moore - Nov. 26, 2012, 9:48 p.m.
On Monday, November 26, 2012 03:41:00 PM Paul Moore wrote:
> On Monday, November 26, 2012 02:59:21 PM Corey Bryant wrote:
> > On 11/26/2012 12:08 PM, Paul Moore wrote:
> > > On Monday, November 26, 2012 11:41:06 AM Corey Bryant wrote:
> > >> On 11/21/2012 10:24 AM, Paul Moore wrote:
> > >>> On Wednesday, November 21, 2012 11:20:44 AM Eduardo Otubo wrote:
> > >>>> Hello folks,
> > >>>> 
> > >>>> Does anyone had a chance to take a look at this? We would like to get
> > >>>> this into the 1.3 release.
> > >>>> 
> > >>>> Thanks again :)
> > >>> 
> > >>> I way a bit delayed due to travel, but I started playing with it a bit
> > >>> yesterday afternoon and unfortunately it still doesn't work for me
> > >>> (using the same test/reproducer I documented in the RH BZ).  I've
> > >>> tried running QEMU both via libvirt and the command line (using a
> > >>> libvirt derived command line).
> > >>> 
> > >>> I'm applying the patches to the F17 QEMU 1.2 package; there is some
> > >>> minor fixup needed in the configure script but nothing major.
> > >>> 
> > >>> What is further frustrating is that the debug code (patch 5/5) doesn't
> > >>> seem to output the problematic syscall.  I wanted to investigate this
> > >>> a bit more before responding, but with the holiday approaching
> > >>> (Thanksgiving in the US), I'm not sure how much progress I'll be able
> > >>> to make for the remainder of this week.  Sorry about that.
> > >>> 
> > >>> If you have any further questions about how, or what, I'm testing,
> > >>> just ask.
> > >> 
> > >> Paul, Is your host 32 or 64-bit?
> > > 
> > > 64-bit
> > 
> > I'm having trouble recreating this.  I'm running a Fedora 17 64-bit host
> > and a Fedora 17 64-bit guest with domain XML that mirrors yours.
> > 
> > Here's the domain XML I'm using and the resulting QEMU command line:
> > 
> > Domain XML:   http://pastebin.com/DWa4RQ1Y
> > Command line: http://pastebin.com/2QTWsUhP
> > 
> > I'm running with QEMU commit 8db972cfa469b4e4afd9c65e54e796b83b5ce3a2
> > which is 1.2.0 with: (a) just the first patch applied, as well as with
> > (b) all of this patch series applied.
> > 
> > Any thoughts on what could be different?
> 
> Like I said earlier, I'm running with the F17 QEMU 1.2 package,
> qemu-1.2.0-16.fc18 to be exact, with Eduardo's patches applied on top.
> 
> I'm currently testing another set of interim patches from Eduardo that was
> sent off-list for testing (you were CC'd); hopefully that will resolve the
> problem.

Unfortunately, the latest patches from Eduardo met with the same fate.  Here 
is more detailed information on my system (HP DL160 G5, F17, 64-bit):

# uname -r
3.6.7-4.fc17.x86_64

[NOTE: standard F17 kernel]

# rpm -qa | grep qemu
qemu-kvm-tools-1.2.0-16.pm5.fc17.x86_64
qemu-common-1.2.0-16.pm5.fc17.x86_64
qemu-kvm-1.2.0-16.pm5.fc17.x86_64
ipxe-roms-qemu-20120328-1.gitaac9718.fc17.noarch
qemu-img-1.2.0-16.pm5.fc17.x86_64
qemu-system-x86-1.2.0-16.pm5.fc17.x86_64

[NOTE: the 'pm5' is my designation indicating the patched version]

# ./qemu_seccomp.sh -sandbox off
char device redirected to /dev/pts/0
do_spice_init: starting 0.10.1
spice_server_add_interface: SPICE_INTERFACE_MIGRATION
spice_server_add_interface: SPICE_INTERFACE_KEYBOARD
spice_server_add_interface: SPICE_INTERFACE_MOUSE
spice_server_add_interface: SPICE_INTERFACE_QXL
red_worker_main: begin
display_channel_create: create display channel
cursor_channel_create: create cursor channel
spice_server_add_interface: SPICE_INTERFACE_PLAYBACK
spice_server_add_interface: SPICE_INTERFACE_RECORD
[NOTE: I hit Ctrl-C at this point]
qemu: terminating on signal 2
spice_server_remove_interface: remove SPICE_INTERFACE_PLAYBACK
spice_server_remove_interface: remove SPICE_INTERFACE_RECORD

# ./qemu_seccomp.sh -sandbox on
char device redirected to /dev/pts/0
do_spice_init: starting 0.10.1
spice_server_add_interface: SPICE_INTERFACE_MIGRATION
spice_server_add_interface: SPICE_INTERFACE_KEYBOARD
spice_server_add_interface: SPICE_INTERFACE_MOUSE
spice_server_add_interface: SPICE_INTERFACE_QXL
red_worker_main: begin
./qemu_seccomp.sh: line 28: 21085 Bad system call         /usr/bin/qemu-kvm -S 
-M pc-0.14 -enable-kvm -m 2048 -smp 2,sockets=2,cores=1,threads=1 -name f16-
test-1 -uuid 13c7da9b-a79a-0688-267a-8206136bc8d6 -nodefconfig -nodefaults -
chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/f16-
test-1.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control 
-rtc base=utc -no-shutdown -device virtio-serial-pci,id=virtio-
serial0,bus=pci.0,addr=0x5 -device piix3-usb-
uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/libvirt/images/f16-
test-1.img,if=none,id=drive-virtio-disk0,format=raw -device virtio-blk-
pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-
disk0,bootindex=1 -netdev user,id=hostnet0 -device virtio-net-
pci,netdev=hostnet0,id=net0,mac=52:54:00:9a:9d:63,bus=pci.0,addr=0x3 -chardev 
pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev 
spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-
serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -
device usb-tablet,id=input0 -spice port=5900,addr=127.0.0.1,disable-ticketing 
-vga qxl -global qxl-vga.vram_size=67108864 -device intel-
hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-
codec0,bus=sound0.0,cad=0 -device virtio-balloon-
pci,id=balloon0,bus=pci.0,addr=0x7 $*

[NOTE: my test script, qemu_seccomp.sh, is attached]
Corey Bryant - Nov. 27, 2012, 4:11 p.m.
On 11/26/2012 04:48 PM, Paul Moore wrote:
> On Monday, November 26, 2012 03:41:00 PM Paul Moore wrote:
>> On Monday, November 26, 2012 02:59:21 PM Corey Bryant wrote:
>>> On 11/26/2012 12:08 PM, Paul Moore wrote:
>>>> On Monday, November 26, 2012 11:41:06 AM Corey Bryant wrote:
>>>>> On 11/21/2012 10:24 AM, Paul Moore wrote:
>>>>>> On Wednesday, November 21, 2012 11:20:44 AM Eduardo Otubo wrote:
>>>>>>> Hello folks,
>>>>>>>
>>>>>>> Does anyone had a chance to take a look at this? We would like to get
>>>>>>> this into the 1.3 release.
>>>>>>>
>>>>>>> Thanks again :)
>>>>>>
>>>>>> I way a bit delayed due to travel, but I started playing with it a bit
>>>>>> yesterday afternoon and unfortunately it still doesn't work for me
>>>>>> (using the same test/reproducer I documented in the RH BZ).  I've
>>>>>> tried running QEMU both via libvirt and the command line (using a
>>>>>> libvirt derived command line).
>>>>>>
>>>>>> I'm applying the patches to the F17 QEMU 1.2 package; there is some
>>>>>> minor fixup needed in the configure script but nothing major.
>>>>>>
>>>>>> What is further frustrating is that the debug code (patch 5/5) doesn't
>>>>>> seem to output the problematic syscall.  I wanted to investigate this
>>>>>> a bit more before responding, but with the holiday approaching
>>>>>> (Thanksgiving in the US), I'm not sure how much progress I'll be able
>>>>>> to make for the remainder of this week.  Sorry about that.
>>>>>>
>>>>>> If you have any further questions about how, or what, I'm testing,
>>>>>> just ask.
>>>>>
>>>>> Paul, Is your host 32 or 64-bit?
>>>>
>>>> 64-bit
>>>
>>> I'm having trouble recreating this.  I'm running a Fedora 17 64-bit host
>>> and a Fedora 17 64-bit guest with domain XML that mirrors yours.
>>>
>>> Here's the domain XML I'm using and the resulting QEMU command line:
>>>
>>> Domain XML:   http://pastebin.com/DWa4RQ1Y
>>> Command line: http://pastebin.com/2QTWsUhP
>>>
>>> I'm running with QEMU commit 8db972cfa469b4e4afd9c65e54e796b83b5ce3a2
>>> which is 1.2.0 with: (a) just the first patch applied, as well as with
>>> (b) all of this patch series applied.
>>>
>>> Any thoughts on what could be different?
>>
>> Like I said earlier, I'm running with the F17 QEMU 1.2 package,
>> qemu-1.2.0-16.fc18 to be exact, with Eduardo's patches applied on top.
>>
>> I'm currently testing another set of interim patches from Eduardo that was
>> sent off-list for testing (you were CC'd); hopefully that will resolve the
>> problem.
>
> Unfortunately, the latest patches from Eduardo met with the same fate.  Here
> is more detailed information on my system (HP DL160 G5, F17, 64-bit):
>
> # uname -r
> 3.6.7-4.fc17.x86_64
>
> [NOTE: standard F17 kernel]
>
> # rpm -qa | grep qemu
> qemu-kvm-tools-1.2.0-16.pm5.fc17.x86_64
> qemu-common-1.2.0-16.pm5.fc17.x86_64
> qemu-kvm-1.2.0-16.pm5.fc17.x86_64
> ipxe-roms-qemu-20120328-1.gitaac9718.fc17.noarch
> qemu-img-1.2.0-16.pm5.fc17.x86_64
> qemu-system-x86-1.2.0-16.pm5.fc17.x86_64
>
> [NOTE: the 'pm5' is my designation indicating the patched version]
>
> # ./qemu_seccomp.sh -sandbox off
> char device redirected to /dev/pts/0
> do_spice_init: starting 0.10.1
> spice_server_add_interface: SPICE_INTERFACE_MIGRATION
> spice_server_add_interface: SPICE_INTERFACE_KEYBOARD
> spice_server_add_interface: SPICE_INTERFACE_MOUSE
> spice_server_add_interface: SPICE_INTERFACE_QXL
> red_worker_main: begin
> display_channel_create: create display channel
> cursor_channel_create: create cursor channel
> spice_server_add_interface: SPICE_INTERFACE_PLAYBACK
> spice_server_add_interface: SPICE_INTERFACE_RECORD
> [NOTE: I hit Ctrl-C at this point]
> qemu: terminating on signal 2
> spice_server_remove_interface: remove SPICE_INTERFACE_PLAYBACK
> spice_server_remove_interface: remove SPICE_INTERFACE_RECORD
>
> # ./qemu_seccomp.sh -sandbox on
> char device redirected to /dev/pts/0
> do_spice_init: starting 0.10.1
> spice_server_add_interface: SPICE_INTERFACE_MIGRATION
> spice_server_add_interface: SPICE_INTERFACE_KEYBOARD
> spice_server_add_interface: SPICE_INTERFACE_MOUSE
> spice_server_add_interface: SPICE_INTERFACE_QXL
> red_worker_main: begin
> ./qemu_seccomp.sh: line 28: 21085 Bad system call         /usr/bin/qemu-kvm -S
> -M pc-0.14 -enable-kvm -m 2048 -smp 2,sockets=2,cores=1,threads=1 -name f16-
> test-1 -uuid 13c7da9b-a79a-0688-267a-8206136bc8d6 -nodefconfig -nodefaults -
> chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/f16-
> test-1.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control
> -rtc base=utc -no-shutdown -device virtio-serial-pci,id=virtio-
> serial0,bus=pci.0,addr=0x5 -device piix3-usb-
> uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/libvirt/images/f16-
> test-1.img,if=none,id=drive-virtio-disk0,format=raw -device virtio-blk-
> pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-
> disk0,bootindex=1 -netdev user,id=hostnet0 -device virtio-net-
> pci,netdev=hostnet0,id=net0,mac=52:54:00:9a:9d:63,bus=pci.0,addr=0x3 -chardev
> pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev
> spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-
> serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -
> device usb-tablet,id=input0 -spice port=5900,addr=127.0.0.1,disable-ticketing
> -vga qxl -global qxl-vga.vram_size=67108864 -device intel-
> hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-
> codec0,bus=sound0.0,cad=0 -device virtio-balloon-
> pci,id=balloon0,bus=pci.0,addr=0x7 $*
>
> [NOTE: my test script, qemu_seccomp.sh, is attached]
>

Thanks for the additional details.  They were very useful.  I was able 
to reproduce this when I manually built spice release 0.10.1, but not 
with the Fedora 0.10.1 package.  One difference I noticed is that the 
Fedora version wasn't logging info messages.

Nonetheless, we'll send new patches soon.  It looks like the following 
were missing: epoll_create, epoll_wait, and epoll_ctl
Paul Moore - Nov. 27, 2012, 4:15 p.m.
On Tuesday, November 27, 2012 11:11:32 AM Corey Bryant wrote:
> Thanks for the additional details.  They were very useful.  I was able
> to reproduce this when I manually built spice release 0.10.1, but not
> with the Fedora 0.10.1 package.  One difference I noticed is that the
> Fedora version wasn't logging info messages.
> 
> Nonetheless, we'll send new patches soon.  It looks like the following
> were missing: epoll_create, epoll_wait, and epoll_ctl

Great, glad to hear my test system wasn't just being stubborn :)

I'll re-test as soon as I see the patches.

Patch

diff --git a/qemu-seccomp.c b/qemu-seccomp.c
index 64329a3..b06a2c6 100644
--- a/qemu-seccomp.c
+++ b/qemu-seccomp.c
@@ -26,8 +26,12 @@  static const struct QemuSeccompSyscall seccomp_whitelist[] = {
     { SCMP_SYS(timer_gettime), 254 },
     { SCMP_SYS(futex), 253 },
     { SCMP_SYS(select), 252 },
+#if defined(__x86_64__)
     { SCMP_SYS(recvfrom), 251 },
     { SCMP_SYS(sendto), 250 },
+#elif defined(__i386__)
+    { SCMP_SYS(socketcall), 250 },
+#endif
     { SCMP_SYS(read), 249 },
     { SCMP_SYS(brk), 248 },
     { SCMP_SYS(clone), 247 },
@@ -36,15 +40,30 @@  static const struct QemuSeccompSyscall seccomp_whitelist[] = {
     { SCMP_SYS(execve), 245 },
     { SCMP_SYS(open), 245 },
     { SCMP_SYS(ioctl), 245 },
+#if defined(__x86_64__)
+    { SCMP_SYS(socket), 245 },
+    { SCMP_SYS(setsockopt), 245 },
     { SCMP_SYS(recvmsg), 245 },
     { SCMP_SYS(sendmsg), 245 },
     { SCMP_SYS(accept), 245 },
     { SCMP_SYS(connect), 245 },
+    { SCMP_SYS(socketpair), 245 },
+    { SCMP_SYS(bind), 245 },
+    { SCMP_SYS(listen), 245 },
+    { SCMP_SYS(semget), 245 },
+#elif defined(__i386__)
+    { SCMP_SYS(ipc), 245 },
+#endif
     { SCMP_SYS(gettimeofday), 245 },
     { SCMP_SYS(readlink), 245 },
     { SCMP_SYS(access), 245 },
     { SCMP_SYS(prctl), 245 },
     { SCMP_SYS(signalfd), 245 },
+    { SCMP_SYS(getrlimit), 245 },
+    { SCMP_SYS(set_tid_address), 245 },
+    { SCMP_SYS(statfs), 245 },
+    { SCMP_SYS(unlink), 245 },
+    { SCMP_SYS(wait4), 245 },
 #if defined(__i386__)
     { SCMP_SYS(fcntl64), 245 },
     { SCMP_SYS(fstat64), 245 },
@@ -56,24 +75,26 @@  static const struct QemuSeccompSyscall seccomp_whitelist[] = {
     { SCMP_SYS(sigreturn), 245 },
     { SCMP_SYS(_newselect), 245 },
     { SCMP_SYS(_llseek), 245 },
-    { SCMP_SYS(mmap2), 245},
+    { SCMP_SYS(mmap2), 245 },
     { SCMP_SYS(sigprocmask), 245 },
-#elif defined(__x86_64__)
-    { SCMP_SYS(sched_getparam), 245},
-    { SCMP_SYS(sched_getscheduler), 245},
-    { SCMP_SYS(fstat), 245},
-    { SCMP_SYS(clock_getres), 245},
-    { SCMP_SYS(sched_get_priority_min), 245},
-    { SCMP_SYS(sched_get_priority_max), 245},
-    { SCMP_SYS(stat), 245},
-    { SCMP_SYS(socket), 245},
-    { SCMP_SYS(setsockopt), 245},
-    { SCMP_SYS(uname), 245},
-    { SCMP_SYS(semget), 245},
 #endif
+    { SCMP_SYS(sched_getparam), 245 },
+    { SCMP_SYS(sched_getscheduler), 245 },
+    { SCMP_SYS(fstat), 245 },
+    { SCMP_SYS(clock_getres), 245 },
+    { SCMP_SYS(sched_get_priority_min), 245 },
+    { SCMP_SYS(sched_get_priority_max), 245 },
+    { SCMP_SYS(stat), 245 },
+    { SCMP_SYS(uname), 245 },
     { SCMP_SYS(eventfd2), 245 },
     { SCMP_SYS(dup), 245 },
+    { SCMP_SYS(dup2), 245 },
+    { SCMP_SYS(dup3), 245 },
     { SCMP_SYS(gettid), 245 },
+    { SCMP_SYS(getgid), 245 },
+    { SCMP_SYS(getegid), 245 },
+    { SCMP_SYS(getuid), 245 },
+    { SCMP_SYS(geteuid), 245 },
     { SCMP_SYS(timer_create), 245 },
     { SCMP_SYS(exit), 245 },
     { SCMP_SYS(clock_gettime), 245 },
@@ -93,8 +114,6 @@  static const struct QemuSeccompSyscall seccomp_whitelist[] = {
     { SCMP_SYS(lseek), 245 },
     { SCMP_SYS(pselect6), 245 },
     { SCMP_SYS(fork), 245 },
-    { SCMP_SYS(bind), 245 },
-    { SCMP_SYS(listen), 245 },
     { SCMP_SYS(eventfd), 245 },
     { SCMP_SYS(rt_sigprocmask), 245 },
     { SCMP_SYS(write), 244 },
@@ -104,10 +123,105 @@  static const struct QemuSeccompSyscall seccomp_whitelist[] = {
     { SCMP_SYS(pipe2), 242 },
     { SCMP_SYS(munmap), 242 },
     { SCMP_SYS(mremap), 242 },
+    { SCMP_SYS(fdatasync), 242 },
+    { SCMP_SYS(close), 242 },
+    { SCMP_SYS(rt_sigpending), 242 },
+    { SCMP_SYS(rt_sigtimedwait), 242 },
+    { SCMP_SYS(readv), 242 },
+    { SCMP_SYS(writev), 242 },
+    { SCMP_SYS(preadv), 242 },
+    { SCMP_SYS(pwritev), 242 },
+    { SCMP_SYS(setrlimit), 242 },
+    { SCMP_SYS(ftruncate), 242 },
+    { SCMP_SYS(lstat), 242 },
+    { SCMP_SYS(pipe), 242 },
+    { SCMP_SYS(umask), 242 },
+    { SCMP_SYS(chdir), 242 },
+    { SCMP_SYS(setitimer), 242 },
+    { SCMP_SYS(setsid), 242 },
+    { SCMP_SYS(poll), 242 },
+#if defined(__i386__)
+    { SCMP_SYS(waitpid), 242 },
+#elif defined(__x86_64__)
     { SCMP_SYS(getsockname), 242 },
     { SCMP_SYS(getpeername), 242 },
-    { SCMP_SYS(fdatasync), 242 },
-    { SCMP_SYS(close), 242 }
+    { SCMP_SYS(accept4), 242 },
+    { SCMP_SYS(newfstatat), 241 },
+    { SCMP_SYS(shutdown), 241 },
+    { SCMP_SYS(getsockopt), 241 },
+    { SCMP_SYS(semctl), 241 },
+    { SCMP_SYS(semop), 241 },
+    { SCMP_SYS(semtimedop), 241 },
+#endif
+    { SCMP_SYS(ppoll), 241 },
+    { SCMP_SYS(creat), 241 },
+    { SCMP_SYS(link), 241 },
+    { SCMP_SYS(getpid), 241 },
+    { SCMP_SYS(getppid), 241 },
+    { SCMP_SYS(getpgrp), 241 },
+    { SCMP_SYS(getpgid), 241 },
+    { SCMP_SYS(getsid), 241 },
+    { SCMP_SYS(getdents64), 241 },
+    { SCMP_SYS(getresuid), 241 },
+    { SCMP_SYS(getresgid), 241 },
+    { SCMP_SYS(getgroups), 241 },
+#if defined(__i386__)
+    { SCMP_SYS(getresuid32), 241 },
+    { SCMP_SYS(getresgid32), 241 },
+    { SCMP_SYS(getgroups32), 241 },
+    { SCMP_SYS(signal), 241 },
+    { SCMP_SYS(sigaction), 241 },
+    { SCMP_SYS(sigsuspend), 241 },
+    { SCMP_SYS(sigpending), 241 },
+    { SCMP_SYS(truncate64), 241 },
+    { SCMP_SYS(ftruncate64), 241 },
+    { SCMP_SYS(fchown32), 241 },
+    { SCMP_SYS(chown32), 241 },
+    { SCMP_SYS(lchown32), 241 },
+    { SCMP_SYS(statfs64), 241 },
+    { SCMP_SYS(fstatfs64), 241 },
+    { SCMP_SYS(fstatat64), 241 },
+    { SCMP_SYS(lstat64), 241 },
+    { SCMP_SYS(sendfile64), 241 },
+    { SCMP_SYS(ugetrlimit), 241 },
+#endif
+    { SCMP_SYS(alarm), 241 },
+    { SCMP_SYS(rt_sigsuspend), 241 },
+    { SCMP_SYS(rt_sigqueueinfo), 241 },
+    { SCMP_SYS(rt_tgsigqueueinfo), 241 },
+    { SCMP_SYS(sigaltstack), 241 },
+    { SCMP_SYS(signalfd4), 241 },
+    { SCMP_SYS(truncate), 241 },
+    { SCMP_SYS(fchown), 241 },
+    { SCMP_SYS(lchown), 241 },
+    { SCMP_SYS(fchownat), 241 },
+    { SCMP_SYS(fstatfs), 241 },
+    { SCMP_SYS(sendfile), 241 },
+    { SCMP_SYS(getitimer), 241 },
+    { SCMP_SYS(syncfs), 241 },
+    { SCMP_SYS(fsync), 241 },
+    { SCMP_SYS(fchdir), 241 },
+    { SCMP_SYS(flock), 241 },
+    { SCMP_SYS(msync), 241 },
+    { SCMP_SYS(sched_setparam), 241 },
+    { SCMP_SYS(sched_setscheduler), 241 },
+    { SCMP_SYS(sched_yield), 241 },
+    { SCMP_SYS(sched_rr_get_interval), 241 },
+    { SCMP_SYS(sched_setaffinity), 241 },
+    { SCMP_SYS(sched_getaffinity), 241 },
+    { SCMP_SYS(readahead), 241 },
+    { SCMP_SYS(timer_getoverrun), 241 },
+    { SCMP_SYS(unlinkat), 241 },
+    { SCMP_SYS(readlinkat), 241 },
+    { SCMP_SYS(faccessat), 241 },
+    { SCMP_SYS(get_robust_list), 241 },
+    { SCMP_SYS(splice), 241 },
+    { SCMP_SYS(vmsplice), 241 },
+    { SCMP_SYS(getcpu), 241 },
+    { SCMP_SYS(sendmmsg), 241 },
+    { SCMP_SYS(recvmmsg), 241 },
+    { SCMP_SYS(prlimit64), 241 },
+    { SCMP_SYS(waitid), 241 }
 };
 
 int seccomp_start(void)