All of lore.kernel.org
 help / color / mirror / Atom feed
From: Corey Bryant <coreyb@linux.vnet.ibm.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: pmoore@redhat.com, aliguori@us.ibm.com, qemu-devel@nongnu.org,
	Eduardo Otubo <otubo@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] [PATCH 4/4] Warning messages on net devices hotplug
Date: Fri, 26 Oct 2012 10:14:12 -0400	[thread overview]
Message-ID: <508A9AB4.50203@linux.vnet.ibm.com> (raw)
In-Reply-To: <5088ECEE.4090104@redhat.com>



On 10/25/2012 03:40 AM, Paolo Bonzini wrote:
> Il 24/10/2012 19:30, Corey Bryant ha scritto:
>>
>>
>> On 10/24/2012 11:45 AM, Paolo Bonzini wrote:
>>> Il 24/10/2012 17:39, Corey Bryant ha scritto:
>>>>
>>>>
>>>> On 10/24/2012 11:21 AM, Paolo Bonzini wrote:
>>>>> Il 24/10/2012 16:18, Corey Bryant ha scritto:
>>>>>>
>>>>>>
>>>>>> On 10/18/2012 11:15 AM, Paolo Bonzini wrote:
>>>>>>> Il 17/10/2012 15:15, Eduardo Otubo ha scritto:
>>>>>>>> With the inclusion of the new "double whitelist" seccomp filter,
>>>>>>>> Qemu
>>>>>>>> won't be able to execve() in runtime, thus, no hotplug net devices
>>>>>>>> allowed.
>>>>>>>>
>>>>>>>> Signed-off-by: Eduardo Otubo <otubo@linux.vnet.ibm.com>
>>>>>>>
>>>>>>> Please check this in net_init_tap instead.  When using libvirt,
>>>>>>> hotplug
>>>>>>> is done with a completely different mechanism that involves
>>>>>>> file-descriptor passing and does not require executing a helper.
>>>>>>>
>>>>>>> Paolo
>>>>>>>
>>>>>>
>>>>>> Are you sure net_init_tap() is the right place for this check?
>>>>>
>>>>> Yes, assuming there is a global that says whether the seccomp
>>>>> sandbox is
>>>>> in effect.  Even something like "if (sandbox_active && !tap->has_fd)
>>>>> error(...)" can be enough.
>>>>>
>>>>> Paolo
>>>>>
>>>>
>>>> What do you think about this? It moves the checks into the functions
>>>> that actually cause execve() to be called, and it only prevents the
>>>> commands after QEMU is done with initialization in main().
>>>
>>> It doesn't do error reporting correctly because these functions do not
>>> get an Error **.  If you change that and use error_setg instead of
>>> error_report, it should be okay.
>>
>> I just wanted to follow up on a few things..
>>
>> All of the following functions currently use qerror_report().  I'm
>> thinking conversion of these and sub-functions to pass an Error **
>> parameter should be a separate undertaking.
>>
>> net_init_nic
>> net_init_slirp
>> net_init_tap
>> net_init_socket
>> net_init_vde
>> net_init_dump
>> net_init_bridge
>> net_init_hubport
>
> Ok, but it should not be hard considering that the immediate caller of
> all these functions (net_client_init1) takes an Error **.  Please
> consider this for 1.4 at least.
>
>>> However, I really think what your testing is not
>>> runstate_is_prelaunch(), it is seccomp_effective().  If you structure
>>> the test like that, it also lets you eliminate the #ifdef (which in
>>> general we prefer to avoid).
>>
>> The reason for testing runstate_is_prelaunch() is because seccomp will
>> be effective during and after prelaunch.  The only difference is that a
>> more restrictive syscall whitelist will be in effect after prelaunch. So
>> perhaps the tests can be similar to the following so that we can get rid
>> of the preprocessor #ifdef:
>>
>> if (seccomp_is_effective() && !runstate_is_prelaunch()) {
>>      error_report("Cannot execute network helper from QEMU monitor "
>>                   "when -sandbox is in effect");
>>      return -1;
>> }
>
> Then you can make the seccomp query return many levels or flags, like
> SECCOMP_SANDBOX_ENABLED | SECCOMP_CAN_EXECVE.
>
> Paolo
>

True, we can do that.  I'll take that approach.  Thanks for the suggestion.

-- 
Regards,
Corey Bryant

  reply	other threads:[~2012-10-26 14:15 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-17 13:15 [Qemu-devel] [PATCH 1/4] Adding new syscalls (bugzilla 855162) Eduardo Otubo
2012-10-17 13:15 ` [Qemu-devel] [PATCH 2/4] Setting "-sandbox on" as deafult Eduardo Otubo
2012-10-18 15:08   ` Corey Bryant
2012-10-17 13:15 ` [Qemu-devel] [PATCH 3/4] Support for "double whitelist" filters Eduardo Otubo
2012-10-19 17:04   ` Blue Swirl
2012-10-19 20:08     ` Corey Bryant
2012-10-19 20:36       ` Eric Blake
2012-10-19 20:46         ` Corey Bryant
2012-10-19 20:03   ` Corey Bryant
2012-10-17 13:15 ` [Qemu-devel] [PATCH 4/4] Warning messages on net devices hotplug Eduardo Otubo
2012-10-18 14:59   ` Corey Bryant
2012-10-18 15:15   ` Paolo Bonzini
2012-10-24 14:18     ` Corey Bryant
2012-10-24 14:34       ` Corey Bryant
2012-10-24 15:21       ` Paolo Bonzini
2012-10-24 15:39         ` Corey Bryant
2012-10-24 15:45           ` Paolo Bonzini
2012-10-24 15:56             ` Corey Bryant
2012-10-24 17:30             ` Corey Bryant
2012-10-25  7:40               ` Paolo Bonzini
2012-10-26 14:14                 ` Corey Bryant [this message]
2012-10-19 19:58 ` [Qemu-devel] [PATCH 1/4] Adding new syscalls (bugzilla 855162) Corey Bryant

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=508A9AB4.50203@linux.vnet.ibm.com \
    --to=coreyb@linux.vnet.ibm.com \
    --cc=aliguori@us.ibm.com \
    --cc=otubo@linux.vnet.ibm.com \
    --cc=pbonzini@redhat.com \
    --cc=pmoore@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /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.