Re: [Qemu-devel] [PATCH] seccomp: adding a second whitelist

[Corey Bryant <coreyb@linux.vnet.ibm.com>]

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