[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCHv2 2/3] seccomp: adding command line support for

From: Eduardo Otubo
Subject: Re: [Qemu-devel] [PATCHv2 2/3] seccomp: adding command line support for blacklist
Date: Tue, 17 Sep 2013 10:01:23 -0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130621 Thunderbird/17.0.7

On 09/11/2013 01:49 PM, Daniel P. Berrange wrote:
On Wed, Sep 11, 2013 at 12:45:54PM -0400, Corey Bryant wrote:

On 09/06/2013 03:21 PM, Eduardo Otubo wrote:
New command line options for the seccomp blacklist feature:

  $ qemu -sandbox on[,strict=<on|off>]

The strict parameter will turn on or off the new system call blacklist

I mentioned this before but I'll say it again since I think it needs
to be discussed.  Since this regresses support (it'll prevent -net
bridge and -net tap from using execv) the concern I have with the
strict=on|off option is whether or not we will have the flexibility
to modify the blacklist once QEMU is released with this support.  Of
course we should be able to add more syscalls to the blacklist as
long as they don't regress QEMU functionality.  But if we want to
add a syscall that does regress QEMU functionality, I think we'd
have to add a new command line option, which doesn't seem desirable.

So a more flexible approach may be necessary.  Maybe the blacklist
should be passed on the command line, which would enable it to be
defined by libvirt and passed to QEMU.  I know Paul is working on
something for libvirt so maybe that answers this question.

Paul, what exactly are you planning to add to libvirt? I'm not a big fan of using qemu command line to pass syscalls for blacklist as arguments, but I can't see other way to avoid problems (like -net bridge / -net tap) from happening.

On the face of it, I'm not at all a fan of the idea of libvirt having
to pass a syscall whitelist/blacklist to QEMU. IMHO that would be
exposing too much knowledge of QEMU impl details to libvirt.


Eduardo Otubo
IBM Linux Technology Center

reply via email to

[Prev in Thread] Current Thread [Next in Thread]