| Message ID | 20180507033214.19219-1-zyimin@linux.ibm.com |
|---|---|
| Headers | show |
| Series | Bug: Sandbox: libvirt breakdowns qemu guest | expand |
On 05/07/2018 05:32 AM, Yi Min Zhao wrote: > 1. Problem Description > ====================== > If QEMU is built without seccomp support, 'elevatorprivileges' remains compiled. > This option of sandbox is treated as an indication for seccomp blacklist support > in libvirt. This behavior is introduced by the libvirt commits 31ca6a5 and > 3527f9d. It would make libvirt build wrong QEMU cmdline, and then the guest > startup would fail. Adding libvirt list. This would still fail with older QEMUs, so the question is if we should also OR instead change something in libvirt. > > 2. Libvirt Log > ============== > qemu-system-s390x: -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,\ > resourcecontrol=deny: seccomp support is disabled > > 3. Fixup > ======== > Wrap the options except 'enable' for qemu_sandbox_opts by CONFIG_SECCOMP. > > Yi Min Zhao (1): > sandbox: avoid to compile options if CONFIG_SECCOMP undefined > > vl.c | 2 ++ > 1 file changed, 2 insertions(+) >
On 07/05/2018 - 11:29:57, Christian Borntraeger wrote: > On 05/07/2018 05:32 AM, Yi Min Zhao wrote: > > 1. Problem Description > > ====================== > > If QEMU is built without seccomp support, 'elevatorprivileges' remains compiled. > > This option of sandbox is treated as an indication for seccomp blacklist support > > in libvirt. This behavior is introduced by the libvirt commits 31ca6a5 and > > 3527f9d. It would make libvirt build wrong QEMU cmdline, and then the guest > > startup would fail. > > Adding libvirt list. > > This would still fail with older QEMUs, so the question is if we should also OR instead > change something in libvirt. Perhaps I'm missing something here, but libvirt can differentiate between different versions of QEMU, therefore not calling it with wrong or outdated arguments. > > > > > 2. Libvirt Log > > ============== > > qemu-system-s390x: -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,\ > > resourcecontrol=deny: seccomp support is disabled > > > > 3. Fixup > > ======== > > Wrap the options except 'enable' for qemu_sandbox_opts by CONFIG_SECCOMP. > > > > Yi Min Zhao (1): > > sandbox: avoid to compile options if CONFIG_SECCOMP undefined > > > > vl.c | 2 ++ > > 1 file changed, 2 insertions(+) > > >
On Mon, May 07, 2018 at 12:33:20PM +0200, Eduardo Otubo wrote: >On 07/05/2018 - 11:29:57, Christian Borntraeger wrote: >> On 05/07/2018 05:32 AM, Yi Min Zhao wrote: >> > 1. Problem Description >> > ====================== >> > If QEMU is built without seccomp support, 'elevatorprivileges' remains compiled. >> > This option of sandbox is treated as an indication for seccomp blacklist support >> > in libvirt. This behavior is introduced by the libvirt commits 31ca6a5 and >> > 3527f9d. It would make libvirt build wrong QEMU cmdline, and then the guest >> > startup would fail. >> >> Adding libvirt list. >> >> This would still fail with older QEMUs, so the question is if we should also OR instead >> change something in libvirt. > >Perhaps I'm missing something here, but libvirt can differentiate between >different versions of QEMU, therefore not calling it with wrong or outdated >arguments. > The code introduced in libvirt commit 31ca6a5 specifically looks for 'elevateprivileges' in 'parameters' of the 'sandbox' option through query-command-line-options. Outdated QEMUs should not have this option there. However, libvirtd does add the option by default not knowing whether it can fail for other reasons, e.g. SECCOMP not being enabled in the running kernel. I wonder if that is worth addressing. Jano >> >> > >> > 2. Libvirt Log >> > ============== >> > qemu-system-s390x: -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,\ >> > resourcecontrol=deny: seccomp support is disabled >> > >> > 3. Fixup >> > ======== >> > Wrap the options except 'enable' for qemu_sandbox_opts by CONFIG_SECCOMP. >> > >> > Yi Min Zhao (1): >> > sandbox: avoid to compile options if CONFIG_SECCOMP undefined >> > >> > vl.c | 2 ++ >> > 1 file changed, 2 insertions(+) >> > >> > >-- >Eduardo Otubo > >-- >libvir-list mailing list >libvir-list@redhat.com >https://www.redhat.com/mailman/listinfo/libvir-list
On 05/07/2018 02:02 PM, Ján Tomko wrote: > On Mon, May 07, 2018 at 12:33:20PM +0200, Eduardo Otubo wrote: >> On 07/05/2018 - 11:29:57, Christian Borntraeger wrote: >>> On 05/07/2018 05:32 AM, Yi Min Zhao wrote: >>> > 1. Problem Description >>> > ====================== >>> > If QEMU is built without seccomp support, 'elevatorprivileges' remains compiled. >>> > This option of sandbox is treated as an indication for seccomp blacklist support >>> > in libvirt. This behavior is introduced by the libvirt commits 31ca6a5 and >>> > 3527f9d. It would make libvirt build wrong QEMU cmdline, and then the guest >>> > startup would fail. >>> >>> Adding libvirt list. >>> >>> This would still fail with older QEMUs, so the question is if we should also OR instead >>> change something in libvirt. >> >> Perhaps I'm missing something here, but libvirt can differentiate between >> different versions of QEMU, therefore not calling it with wrong or outdated >> arguments. >> > > The code introduced in libvirt commit 31ca6a5 specifically looks for > 'elevateprivileges' in 'parameters' of the 'sandbox' option through > query-command-line-options. > > Outdated QEMUs should not have this option there. > > However, libvirtd does add the option by default not knowing whether it > can fail for other reasons, e.g. SECCOMP not being enabled in the > running kernel. I wonder if that is worth addressing. So you prefer the qemu patch (with cc stable) as the best solution?