On Wed, Oct 30, 2013 at 11:04:39AM +0100, Stefan Hajnoczi wrote: > On Wed, Oct 23, 2013 at 12:42:34PM -0200, Eduardo Otubo wrote: > > On 10/22/2013 11:00 AM, Anthony Liguori wrote: > > >On Tue, Oct 22, 2013 at 12:21 PM, Eduardo Otubo > > ><ot...@linux.vnet.ibm.com> wrote: > > >>Inverting the way sandbox handles arguments, making possible to have no > > >>argument and still have '-sandbox on' enabled. > > >> > > >>Signed-off-by: Eduardo Otubo <ot...@linux.vnet.ibm.com> > > >>--- > > >> > > >>The option '-sandbox on' is now used by default by virt-test[0] -- it has > > >>been > > >>merged into the 'next' branch and will be available in the next release, > > >>meaning we have a back support for regression tests if anything breaks > > >>because > > >>of some missing system call not listed in the whitelist. > > >> > > >>This being said, I think it makes sense to have this option set to 'on' by > > >>default in the next Qemu version. It's been a while since no missing > > >>syscall is > > >>reported and at this point the whitelist seems to be pretty mature. > > >> > > >>[0] - > > >>https://github.com/autotest/virt-test/commit/50e1f7d47a94f4c770880cd8ec0f18365dcba714 > > > > > >This breaks hot_add of a network device that uses a script= argument, > > >correct? > > > > > >If so, this cannot be made default. > > > > Anthony, I believe you're talking about the blacklist feature. This > > is the old whitelist that is already upstream and it does not block > > any network device to be hot plugged. > > The following fails to start here (the shell hangs and ps shows QEMU is > a <defunct> process): > > qemu-system-x86_64 -sandbox on -enable-kvm -m 1024 -cpu host \ > -drive if=virtio,cache=none,file=test.img > > It is using the GTK UI.
IMO this seccomp approach is doomed since QEMU does not practice privilege separation. QEMU is monolithic so it's really hard to create a meaningful sets of system calls. To avoid breaking stuff you need to be too liberal, defeating the purpose of seccomp. For each QEMU command-line there may be a different set of syscalls that should be allowed/forbidden. The existing approach clearly doesn't support the full range of options that users specify on the command-line. So I guess the options are: 1. Don't make it the default since it breaks stuff but use it for very specific scenarios (e.g. libvirt use cases that have been well tested). 2. Provide a kind of syscall set for various QEMU options and apply the union of them at launch. This still seems fragile but in theory it could work. Stefan