Re: [Qemu-devel] [RFC] [PATCHv2 2/2] Adding basic calls to libseccomp in vl.c

["Daniel P. Berrange" <berrange@redhat.com>]

On Fri, Jun 15, 2012 at 07:06:10PM +0000, Blue Swirl wrote:
> On Wed, Jun 13, 2012 at 8:30 PM, Daniel P. Berrange <berrange@redhat.com> wrote:
> > On Wed, Jun 13, 2012 at 04:20:22PM -0300, Eduardo Otubo wrote:
> >> I added a syscall struct using priority levels as described in the
> >> libseccomp man page. The priority numbers are based to the frequency
> >> they appear in a sample strace from a regular qemu guest run under
> >> libvirt.
> >>
> >> Libseccomp generates linear BPF code to filter system calls, those rules
> >> are read one after another. The priority system places the most common
> >> rules first in order to reduce the overhead when processing them.
> >>
> >> Also, since this is just a first RFC, the whitelist is a little raw. We
> >> might need your help to improve, test and fine tune the set of system
> >> calls.
> >>
> >> v2: Fixed some style issues
> >>       Removed code from vl.c and created qemu-seccomp.[ch]
> >>       Now using ARRAY_SIZE macro
> >>       Added more syscalls without priority/frequency set yet
> >>
> >> Signed-off-by: Eduardo Otubo <otubo@linux.vnet.ibm.com>
> >> ---
> >>  qemu-seccomp.c |   73 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >>  qemu-seccomp.h |    9 +++++++
> >>  vl.c           |    7 ++++++
> >>  3 files changed, 89 insertions(+)
> >>  create mode 100644 qemu-seccomp.c
> >>  create mode 100644 qemu-seccomp.h
> >>
> >> diff --git a/qemu-seccomp.c b/qemu-seccomp.c
> >> new file mode 100644
> >> index 0000000..048b7ba
> >> --- /dev/null
> >> +++ b/qemu-seccomp.c
> >> @@ -0,0 +1,73 @@
> >> +#include <stdio.h>
> >> +#include <seccomp.h>
> >> +#include "qemu-seccomp.h"
> >> +
> >> +static struct QemuSeccompSyscall seccomp_whitelist[] = {
> >> +    { SCMP_SYS(timer_settime), 255 },
> >> +    { SCMP_SYS(timer_gettime), 254 },
> >> +    { SCMP_SYS(futex), 253 },
> >> +    { SCMP_SYS(select), 252 },
> >> +    { SCMP_SYS(recvfrom), 251 },
> >> +    { SCMP_SYS(sendto), 250 },
> >> +    { SCMP_SYS(read), 249 },
> >> +    { SCMP_SYS(brk), 248 },
> >> +    { SCMP_SYS(clone), 247 },
> >> +    { SCMP_SYS(mmap), 247 },
> >> +    { SCMP_SYS(mprotect), 246 },
> >> +    { SCMP_SYS(ioctl), 245 },
> >> +    { SCMP_SYS(recvmsg), 245 },
> >> +    { SCMP_SYS(sendmsg), 245 },
> >> +    { SCMP_SYS(accept), 245 },
> >> +    { SCMP_SYS(connect), 245 },
> >> +    { SCMP_SYS(bind), 245 },
> >> +    { SCMP_SYS(listen), 245 },
> >> +    { SCMP_SYS(ioctl), 245 },
> >> +    { SCMP_SYS(eventfd), 245 },
> >> +    { SCMP_SYS(rt_sigprocmask), 245 },
> >> +    { SCMP_SYS(write), 244 },
> >> +    { SCMP_SYS(fcntl), 243 },
> >> +    { SCMP_SYS(tgkill), 242 },
> >> +    { SCMP_SYS(rt_sigaction), 242 },
> >> +    { SCMP_SYS(pipe2), 242 },
> >> +    { SCMP_SYS(munmap), 242 },
> >> +    { SCMP_SYS(mremap), 242 },
> >> +    { SCMP_SYS(getsockname), 242 },
> >> +    { SCMP_SYS(getpeername), 242 },
> >> +    { SCMP_SYS(fdatasync), 242 },
> >> +    { SCMP_SYS(close), 242 }
> >
> > execve(), so QEMU can run things like the ifup/down
> > scripts, the samba daemon (sic), exec: migration protocol,
> > etc, etc
> 
> I think allowing execve() would render seccomp pretty much useless.

So do I, but in the previous posting it was stated[1] that the
intent is to allow all syscalls QEMU needs, and not have
any loss of current functionality. Hence I'm reporting all syscalls
that are missing that QEMU needs.


Daniel

[1]  https://lists.gnu.org/archive/html/qemu-devel/2012-05/msg00928.html
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|