On 8/29/23 19:05, Michael S. Tsirkin wrote:
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
Does that make sense?
OK. How are we going to enforce it?
Actually, it seems already enforced for all VDPA devices types.
Indeed, the VDPA_CMD_DEV_NEW Netlink command used to add the device to
the VDPA bus has the GENL_ADMIN_PERM flag set, and so require
Also, we need a way for selinux to enable/disable some of these things
but not others.
Ok, I can do it in a patch on top.
Do you have a pointer where it is done for Virtio Block devices?
Virtualization mailing list