All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Maxime Coquelin <maxime.coquelin@redhat.com>
Cc: xuanzhuo@linux.alibaba.com, lulu@redhat.com, eperezma@redhat.com,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	xieyongji@bytedance.com, Jakub Kicinski <kuba@kernel.org>,
	david.marchand@redhat.com
Subject: Re: [PATCH v3 0/3] vduse: add support for networking devices
Date: Tue, 29 Aug 2023 13:05:35 -0400	[thread overview]
Message-ID: <20230829130430-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <ad2b2f93-3598-cffc-0f0d-fe20b2444011@redhat.com>

On Tue, Aug 29, 2023 at 03:34:06PM +0200, Maxime Coquelin wrote:
> 
> 
> On 8/11/23 00:00, Jakub Kicinski wrote:
> > On Thu, 10 Aug 2023 17:42:11 -0400 Michael S. Tsirkin wrote:
> > > > Directly into the stack? I thought VDUSE is vDPA in user space,
> > > > meaning to get to the kernel the packet has to first go thru
> > > > a virtio-net instance.
> > > 
> > > yes. is that a sufficient filter in your opinion?
> > 
> > Yes, the ability to create the device feels stronger than CAP_NET_RAW,
> > and a bit tangential to CAP_NET_ADMIN. But I don't have much practical
> > experience with virt so no strong opinion, perhaps it does make sense
> > for someone's deployment? Dunno..
> > 
> 
> I'm not sure CAP_NET_ADMIN should be required for creating the VDUSE
> devices, as the device could be attached to vhost-vDPA and so not
> visible to the Kernel networking stack.
> 
> However, CAP_NET_ADMIN should be required to attach the VDUSE device to
> virtio-vdpa/virtio-net.
> 
> Does that make sense?
> 
> Maxime

OK. How are we going to enforce it?
Also, we need a way for selinux to enable/disable some of these things
but not others.

-- 
MST

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Maxime Coquelin <maxime.coquelin@redhat.com>
Cc: Jakub Kicinski <kuba@kernel.org>,
	xieyongji@bytedance.com, jasowang@redhat.com,
	david.marchand@redhat.com, lulu@redhat.com,
	linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	netdev@vger.kernel.org, xuanzhuo@linux.alibaba.com,
	eperezma@redhat.com
Subject: Re: [PATCH v3 0/3] vduse: add support for networking devices
Date: Tue, 29 Aug 2023 13:05:35 -0400	[thread overview]
Message-ID: <20230829130430-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <ad2b2f93-3598-cffc-0f0d-fe20b2444011@redhat.com>

On Tue, Aug 29, 2023 at 03:34:06PM +0200, Maxime Coquelin wrote:
> 
> 
> On 8/11/23 00:00, Jakub Kicinski wrote:
> > On Thu, 10 Aug 2023 17:42:11 -0400 Michael S. Tsirkin wrote:
> > > > Directly into the stack? I thought VDUSE is vDPA in user space,
> > > > meaning to get to the kernel the packet has to first go thru
> > > > a virtio-net instance.
> > > 
> > > yes. is that a sufficient filter in your opinion?
> > 
> > Yes, the ability to create the device feels stronger than CAP_NET_RAW,
> > and a bit tangential to CAP_NET_ADMIN. But I don't have much practical
> > experience with virt so no strong opinion, perhaps it does make sense
> > for someone's deployment? Dunno..
> > 
> 
> I'm not sure CAP_NET_ADMIN should be required for creating the VDUSE
> devices, as the device could be attached to vhost-vDPA and so not
> visible to the Kernel networking stack.
> 
> However, CAP_NET_ADMIN should be required to attach the VDUSE device to
> virtio-vdpa/virtio-net.
> 
> Does that make sense?
> 
> Maxime

OK. How are we going to enforce it?
Also, we need a way for selinux to enable/disable some of these things
but not others.

-- 
MST


  reply	other threads:[~2023-08-29 17:05 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-05 10:04 [PATCH v3 0/3] vduse: add support for networking devices Maxime Coquelin
2023-07-05 10:04 ` Maxime Coquelin
2023-07-05 10:04 ` [PATCH v3 1/3] vduse: validate block features only with block devices Maxime Coquelin
2023-07-05 10:04   ` Maxime Coquelin
2023-07-05 10:04 ` [PATCH v3 2/3] vduse: enable Virtio-net device type Maxime Coquelin
2023-07-05 10:04   ` Maxime Coquelin
2023-07-05 10:04 ` [PATCH v3 3/3] vduse: Temporarily disable control queue features Maxime Coquelin
2023-07-05 10:04   ` Maxime Coquelin
2023-07-06  1:58   ` Jason Wang
2023-07-06  1:58     ` Jason Wang
2023-08-10 19:04 ` [PATCH v3 0/3] vduse: add support for networking devices Michael S. Tsirkin
2023-08-10 19:04   ` Michael S. Tsirkin
2023-08-10 21:29   ` Jakub Kicinski
2023-08-10 21:42     ` Michael S. Tsirkin
2023-08-10 21:42       ` Michael S. Tsirkin
2023-08-10 22:00       ` Jakub Kicinski
2023-08-29 13:34         ` Maxime Coquelin
2023-08-29 13:34           ` Maxime Coquelin
2023-08-29 17:05           ` Michael S. Tsirkin [this message]
2023-08-29 17:05             ` Michael S. Tsirkin
2023-08-30 11:27             ` Maxime Coquelin
2023-08-30 11:27               ` Maxime Coquelin
2023-08-30 13:30               ` Michael S. Tsirkin
2023-08-30 13:30                 ` Michael S. Tsirkin

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=20230829130430-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=david.marchand@redhat.com \
    --cc=eperezma@redhat.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lulu@redhat.com \
    --cc=maxime.coquelin@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=xieyongji@bytedance.com \
    --cc=xuanzhuo@linux.alibaba.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.