From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44970) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SfbpW-0004u7-RC for qemu-devel@nongnu.org; Fri, 15 Jun 2012 15:05:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SfbpU-0007Jm-IJ for qemu-devel@nongnu.org; Fri, 15 Jun 2012 15:05:10 -0400 Received: from mail-gh0-f173.google.com ([209.85.160.173]:62328) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SfbpU-0007Fd-Aw for qemu-devel@nongnu.org; Fri, 15 Jun 2012 15:05:08 -0400 Received: by ghrr14 with SMTP id r14so2826825ghr.4 for ; Fri, 15 Jun 2012 12:05:05 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20120613203305.GC6019@redhat.com> References: <20120613203305.GC6019@redhat.com> From: Blue Swirl Date: Fri, 15 Jun 2012 19:04:45 +0000 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC] [PATCHv2 2/2] Adding basic calls to libseccomp in vl.c List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: qemu-devel@nongnu.org, Eduardo Otubo On Wed, Jun 13, 2012 at 8:33 PM, Daniel P. Berrange w= rote: > On Wed, Jun 13, 2012 at 07:56:06PM +0000, Blue Swirl wrote: >> On Wed, Jun 13, 2012 at 7:20 PM, 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 rul= es >> > 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. W= e >> > might need your help to improve, test and fine tune the set of system >> > calls. >> > >> > v2: Fixed some style issues >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0Removed code from vl.c and created qemu-sec= comp.[ch] >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0Now using ARRAY_SIZE macro >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0Added more syscalls without priority/freque= ncy set yet >> > >> > Signed-off-by: Eduardo Otubo >> > --- >> > =C2=A0qemu-seccomp.c | =C2=A0 73 +++++++++++++++++++++++++++++++++++++= +++++++++++++++++++ >> > =C2=A0qemu-seccomp.h | =C2=A0 =C2=A09 +++++++ >> > =C2=A0vl.c =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A07 ++++++ >> > =C2=A03 files changed, 89 insertions(+) >> > =C2=A0create mode 100644 qemu-seccomp.c >> > =C2=A0create 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 @@ >> >> Copyright and license info missing. >> >> > +#include >> > +#include >> > +#include "qemu-seccomp.h" >> > + >> > +static struct QemuSeccompSyscall seccomp_whitelist[] =3D { >> >> 'const' >> >> > + =C2=A0 =C2=A0{ SCMP_SYS(timer_settime), 255 }, >> > + =C2=A0 =C2=A0{ SCMP_SYS(timer_gettime), 254 }, >> > + =C2=A0 =C2=A0{ SCMP_SYS(futex), 253 }, >> > + =C2=A0 =C2=A0{ SCMP_SYS(select), 252 }, >> > + =C2=A0 =C2=A0{ SCMP_SYS(recvfrom), 251 }, >> > + =C2=A0 =C2=A0{ SCMP_SYS(sendto), 250 }, >> > + =C2=A0 =C2=A0{ SCMP_SYS(read), 249 }, >> > + =C2=A0 =C2=A0{ SCMP_SYS(brk), 248 }, >> > + =C2=A0 =C2=A0{ SCMP_SYS(clone), 247 }, >> > + =C2=A0 =C2=A0{ SCMP_SYS(mmap), 247 }, >> > + =C2=A0 =C2=A0{ SCMP_SYS(mprotect), 246 }, >> > + =C2=A0 =C2=A0{ SCMP_SYS(ioctl), 245 }, >> > + =C2=A0 =C2=A0{ SCMP_SYS(recvmsg), 245 }, >> > + =C2=A0 =C2=A0{ SCMP_SYS(sendmsg), 245 }, >> > + =C2=A0 =C2=A0{ SCMP_SYS(accept), 245 }, >> > + =C2=A0 =C2=A0{ SCMP_SYS(connect), 245 }, >> > + =C2=A0 =C2=A0{ SCMP_SYS(bind), 245 }, >> >> It would be nice to avoid connect() and bind(). Perhaps seccomp init >> should be postponed to after all sockets have been created? > > If you want to migrate your guest, you need to be able to > call connect() at an arbitrary point in the QEMU process' > lifecycle. So you can't avoid allowing connect(). Similarly > if you want to allow hotplug of NICs (and their backends) > then you need to have both bind() + connect() available. That's bad. Migration could conceivably be extended to use file descriptor passing, but hotplug is more tricky. It's probably easier to split QEMU to two processes, one with greater rights like bind(), connect() etc. and another with tighter set. > > > Daniel > -- > |: http://berrange.com =C2=A0 =C2=A0 =C2=A0-o- =C2=A0 =C2=A0http://www.fl= ickr.com/photos/dberrange/ :| > |: http://libvirt.org =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-o-= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://virt-manager.org :| > |: http://autobuild.org =C2=A0 =C2=A0 =C2=A0 -o- =C2=A0 =C2=A0 =C2=A0 =C2= =A0 http://search.cpan.org/~danberr/ :| > |: http://entangle-photo.org =C2=A0 =C2=A0 =C2=A0 -o- =C2=A0 =C2=A0 =C2= =A0 http://live.gnome.org/gtk-vnc :|