On Thu, Aug 30, 2018 at 02:37:48PM +0200, Marc-André Lureau wrote:
Hi
On Thu, Aug 30, 2018 at 2:25 PM, Ján Tomko <jtomko(a)redhat.com> wrote:
> On Thu, Aug 30, 2018 at 02:09:41PM +0200, marcandre.lureau(a)redhat.com wrote:
>>
>> From: Marc-André Lureau <marcandre.lureau(a)redhat.com>
>>
>> With qemu <= 3.0, when using "-seccomp on", the seccomp policy is
only
>> applied to the main thread, the vcpu worker thread and other worker
>> threads created after seccomp policy is applied; the seccomp policy is
>> not applied to e.g. the RCU thread because it is created before the
>> seccomp policy is applied.
>>
>> Since qemu commit 70dfabeaa79ba4d7a3b699abe1a047c8012db114 "seccomp:
>> set the seccomp filter to all threads", qemu will require seccomp
>> TSYNC flag, and will fail to start if the flag isn't available.
>>
>> Without it, sandboxing is flawed. Disable seccomp capability if the
>> host is not capable of using seccomp TSYNC.
>>
>
> Is there a reason for qemu to advertise 'sandbox' in
> query-commandline-options if it's not usable?
>
I suppose qemu could probe for the host support, and remove the
-sandbox option if host is not capable.
The problem would remain for older versions of qemu though.
So maybe a better plan is to:
- remove sandbox capability if qemu < 3.1
- disable -sandbox in qemu if host doesn't support TSYNC
If we do the check for qemu < 3.1, then libvirt breaks if a distro
backports the fix (eg to RHEL-7).
If we don't check for qemu < 3.1, then we used -sandbox, but it has
no benefit because its trivially escaped from other threads. This is
no worse than how it has worked for entire of existance of the -sandbox
command.
So probably on balance it sufficient to just make QEMU hide -sandbox
if TSYNC is missing, and ignore the question of old QEMUs.
Regards,
Daniel
--
|:
https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
|:
https://libvirt.org -o-
https://fstop138.berrange.com :|
|:
https://entangle-photo.org -o-
https://www.instagram.com/dberrange :|