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
What do you think?