Hi On Thu, Aug 30, 2018 at 2:25 PM, Ján Tomko <jtomko@xxxxxxxxxx> wrote: > On Thu, Aug 30, 2018 at 02:09:41PM +0200, marcandre.lureau@xxxxxxxxxx wrote: >> >> From: Marc-André Lureau <marcandre.lureau@xxxxxxxxxx> >> >> 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? -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
