Re: [Qemu-devel] [PATCH v2 1/1] sandbox: disable -sandbox if CONFIG_SECCOMP undefined

[Eduardo Otubo <otubo@redhat.com>]

On 05/23/2018 02:17 PM, Yi Min Zhao wrote:
> 
> 
> 在 2018/5/23 下午6:33, Eduardo Otubo 写道:
>> On 05/23/2018 11:16 AM, Yi Min Zhao wrote:
>>>
>>>
>>> 在 2018/5/23 下午3:47, Ján Tomko 写道:
>>>> On Sat, May 19, 2018 at 04:20:37PM +0800, Yi Min Zhao wrote:
>>>>>
>>>>>
>>>>> 在 2018/5/18 下午9:07, Ján Tomko 写道:
>>>>>> On Fri, May 18, 2018 at 11:19:16AM +0200, Eduardo Otubo wrote:
>>>>>>> On 18/05/2018 - 09:52:12, Ján Tomko wrote:
>>>>>>>> But now libvirt requires QEMU >= 1.5.0 which already supports
>>>>>>>> query-command-line-options, so if you want the option gone 
>>>>>>>> completely
>>>>>>>> --without-seccomp, I can add the code that probes for it and
>>>>>>>> make seccomp_sandbox = 0 a no-op if it's compiled out.
>>>>>>>
>>>>>>> This looks like a good solution for the libvirt side. Can you add
>>>>>>> this support
>>>>>>> so we can merge this fix?
>>>>>>>
>>>>>>
>>>>>> Patches proposed:
>>>>>> https://www.redhat.com/archives/libvir-list/2018-May/msg01430.html
>>>>>>
>>>>>> Jano
>>>>> Thanks for your work!
>>>>
>>>> Now pushed in libvirt master:
>>>> commit b87222a90919040c12fb6d7c8dcc20f944a66495
>>>> Author:     Ján Tomko <jtomko@redhat.com>
>>>> AuthorDate: 2018-05-18 14:57:51 +0200
>>>> Commit:     Ján Tomko <jtomko@redhat.com>
>>>> CommitDate: 2018-05-23 09:45:48 +0200
>>>>
>>>>    qemu: only pass -sandbox off if supported
>>>>
>>>>    This way we don't rely on QEMU supplying the -sandbox option
>>>>    without CONFIG_SECCOMP.
>>>>
>>>>    Signed-off-by: Ján Tomko <jtomko@redhat.com>
>>>>    Reviewed-by: John Ferlan <jferlan@redhat.com>
>>>>
>>>> git describe: v4.3.0-258-gb87222a909
>>>> https://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=b87222a90919040c12fb6d7c8dcc20f944a66495 
>>>>
>>>>
>>>> Jano
>>> Thanks! But I have not got response from Paolo.  I have added him to 
>>> CC list.
>>>
>>  I'll just wait one more ACK and will send a pull request on the 
>> seccomp queue. Thanks for the contribution.
>>
>>
> So... what I should do is wait?
> 
Yes, even though I think we're safe to proceed without his explicit ack.