All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ján Tomko" <jtomko@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: Yi Min Zhao <zyimin@linux.ibm.com>,
	qemu-devel@nongnu.org, otubo@redhat.com, fiuczy@linux.ibm.com,
	borntraeger@de.ibm.com, jferlan@redhat.com
Subject: Re: [Qemu-devel] [PATCH 1/1] sandbox: avoid to compile options if CONFIG_SECCOMP undefined
Date: Wed, 9 May 2018 16:23:47 +0200	[thread overview]
Message-ID: <20180509142347.GD25952@dnr> (raw)
In-Reply-To: <e4041508-c6ba-5e83-8bd8-50a4bd996009@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2125 bytes --]

On Mon, May 07, 2018 at 01:04:17PM -0500, Eric Blake wrote:
>On 05/06/2018 10:32 PM, Yi Min Zhao wrote:
>
>In the subject line: s/avoid to compile/avoid compiling/
>
>> If CONFIG_SECCOMP is undefined, the option 'elevatorprivileges' remains
>
>s/elevator/elevate/
>
>> complied. This would make libvirt set the corresponding capability and
>
>s/complied/compiled/
>
>> then trigger the guest startup fails. So let's wrap the options with
>> CONFIG_SECCOMP.
>>
>> Signed-off-by: Yi Min Zhao <zyimin@linux.ibm.com>
>> ---
>>   vl.c | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/vl.c b/vl.c
>> index fce1fd12d8..cb07b19c02 100644
>> --- a/vl.c
>> +++ b/vl.c
>> @@ -268,6 +268,7 @@ static QemuOptsList qemu_sandbox_opts = {
>>               .name = "enable",
>>               .type = QEMU_OPT_BOOL,
>>           },
>> +#ifdef CONFIG_SECCOMP
>>           {
>>               .name = "obsolete",
>>               .type = QEMU_OPT_STRING,
>> @@ -284,6 +285,7 @@ static QemuOptsList qemu_sandbox_opts = {
>>               .name = "resourcecontrol",
>>               .type = QEMU_OPT_STRING,
>>           },
>> +#endif
>
>The commit message mentions only 'elevateprivileges' (once the typo is
>fixed), but you are also crippling 'obsolete', 'spawn', and
>'resourcecontrol'.  Perhaps the commit message should call that out
>better?  Or, since libvirt is looking at just 'elevateprivileges', per
>this line in libvirt's qemu_capabilities.c:
>
>src/qemu/qemu_capabilities.c:    { "sandbox", "elevateprivileges",
>QEMU_CAPS_SECCOMP_BLACKLIST },
>
>is it sufficient to just mask out that one option?

That would be inconsistent. I picked one option randomly, because they
were added at the same time, but compiling out just one out of four
is just odd. And with leaving them in even though the functionality is
compiled out, libvirt has no way to tell upfront whether it's usable.

By that logic, removing the -sandbox option without CONFIG_SECCOMP makes
sense, but libvirt already assumes this option is present on all supported
QEMUs (>= 1.5.0), so please cc: me on that change if you decide to
remove it as well.

Jano

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2018-05-09 14:23 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-07  3:32 [Qemu-devel] [PATCH 0/1] Bug: Sandbox: libvirt breakdowns qemu guest Yi Min Zhao
2018-05-07  3:32 ` [Qemu-devel] [PATCH 1/1] sandbox: avoid to compile options if CONFIG_SECCOMP undefined Yi Min Zhao
2018-05-07 10:31   ` Eduardo Otubo
2018-05-07 13:27     ` Yi Min Zhao
2018-05-07 18:04   ` Eric Blake
2018-05-07 22:18     ` Yi Min Zhao
2018-05-08 10:37     ` Daniel P. Berrangé
2018-05-09  4:40       ` Yi Min Zhao
2018-05-09 12:48         ` Eric Blake
2018-05-09 14:23     ` Ján Tomko [this message]
2018-05-07  9:29 ` [Qemu-devel] [PATCH 0/1] Bug: Sandbox: libvirt breakdowns qemu guest Christian Borntraeger
2018-05-07 10:33   ` Eduardo Otubo
2018-05-07 12:02     ` [Qemu-devel] [libvirt] " Ján Tomko
2018-05-07 12:12       ` Christian Borntraeger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180509142347.GD25952@dnr \
    --to=jtomko@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=eblake@redhat.com \
    --cc=fiuczy@linux.ibm.com \
    --cc=jferlan@redhat.com \
    --cc=otubo@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=zyimin@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.