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@redhat.com> wrote:
On Thu, Aug 30, 2018 at 02:09:41PM +0200, marcandre.lureau@redhat.com wrote:
From: Marc-André Lureau <marcandre.lureau@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 :|