| Message ID | 1352749698-1219-1-git-send-email-otubo@linux.vnet.ibm.com |
|---|---|
| State | New |
| Headers | show |
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 >
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.
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
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?
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
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?
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.
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]
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
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.
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)
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(-)