On 09/03/2013 04:05 PM, Eduardo Otubo wrote:
On 09/03/2013 03:02 PM, Corey Bryant wrote:
On 08/30/2013 10:21 AM, Eduardo Otubo wrote:
On 08/29/2013 05:34 AM, Stefan Hajnoczi wrote:
On Wed, Aug 28, 2013 at 10:04:32PM -0300, Eduardo Otubo wrote:
Now there's a second whitelist, right before the vcpu starts. The
second
whitelist is the same as the first one, except for exec() and
select().
-netdev tap,downscript=/path/to/script requires exec() in the QEMU
shutdown code path. Will this work with seccomp?
I actually don't know, but I'll test that as well. Can you run a test
with this patch and -netdev? I mean, if you're pointing that out you
might have a scenario already setup, right?
Thanks!
This uses exec() in net/tap.c.
I think if we're going to introduce a sandbox environment that restricts
existing QEMU behavior, then we have to introduce a new argument to the
-sandbox option. So for example, "-sandbox on" would continue to use
the whitelist that allows everything in QEMU to work (or at least it
should :). And something like "-sandbox on,strict=on" would use the
whitelist + blacklist.
I think tihs is very reasonable. I'll working on implementing this
options for v2.
If this is acceptable though, then I wonder how we could go about adding
new syscalls to the blacklist in future QEMU releases without regressing
"-sandbox on,strict=on".
By the way, are any test buckets running regularly with -sandbox on?
I am running tests with virt-test. Need to come up with a script that
checks for unused syscalls, though.
Would it be possible to submit a patch to turn on -sandbox for some/all
QEMU virt-test tests? That would enable regular regression runs that
aren't dependent on you. Plus it would be a good proof point of the
QEMU seccomp support if the tests run successfully.
--
Regards,
Corey Bryant
