Re: vhost-net todo list
On Wednesday 16 September 2009, Michael S. Tsirkin wrote: Also, I might not want to allow the user to open a random random raw socket, but only one on a specific downstream port of a macvlan interface, so I can filter out the data from that respective MAC address in an external switch. I agree. Maybe we can fix that for raw sockets, want me to add it to the list? :) So far, I could not find any theoretical solution how to fix this, but if you think it can be done, it would be good to have it on the list somewhere. Arnd -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: vhost-net todo list
On Thu, Sep 17, 2009 at 01:30:00PM +0200, Arnd Bergmann wrote: On Wednesday 16 September 2009, Michael S. Tsirkin wrote: Also, I might not want to allow the user to open a random random raw socket, but only one on a specific downstream port of a macvlan interface, so I can filter out the data from that respective MAC address in an external switch. I agree. Maybe we can fix that for raw sockets, want me to add it to the list? :) So far, I could not find any theoretical solution how to fix this, What if socket had a LOCKBIND ioctl after which you can not bind it to any other device? Then someone with RAW capability can open the socket, bind to device and hand it to you. You can send packets but not switch to another device. but if you think it can be done, it would be good to have it on the list somewhere. Arnd -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: vhost-net todo list
On Thursday 17 September 2009, Michael S. Tsirkin wrote: On Thu, Sep 17, 2009 at 01:30:00PM +0200, Arnd Bergmann wrote: On Wednesday 16 September 2009, Michael S. Tsirkin wrote: Also, I might not want to allow the user to open a random random raw socket, but only one on a specific downstream port of a macvlan interface, so I can filter out the data from that respective MAC address in an external switch. I agree. Maybe we can fix that for raw sockets, want me to add it to the list? :) So far, I could not find any theoretical solution how to fix this, What if socket had a LOCKBIND ioctl after which you can not bind it to any other device? Then someone with RAW capability can open the socket, bind to device and hand it to you. You can send packets but not switch to another device. Could work, though I was hoping for a solution that does not depend on a priviledged task at run time to open the socket, as you have with persistant tap devices or chardevs like macvtap that can have their persissions set by udev. Arnd -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: vhost-net todo list
On Thu, Sep 17, 2009 at 02:14:06PM +0200, Arnd Bergmann wrote: On Thursday 17 September 2009, Michael S. Tsirkin wrote: On Thu, Sep 17, 2009 at 01:30:00PM +0200, Arnd Bergmann wrote: On Wednesday 16 September 2009, Michael S. Tsirkin wrote: Also, I might not want to allow the user to open a random random raw socket, but only one on a specific downstream port of a macvlan interface, so I can filter out the data from that respective MAC address in an external switch. I agree. Maybe we can fix that for raw sockets, want me to add it to the list? :) So far, I could not find any theoretical solution how to fix this, What if socket had a LOCKBIND ioctl after which you can not bind it to any other device? Then someone with RAW capability can open the socket, bind to device and hand it to you. You can send packets but not switch to another device. Could work, though I was hoping for a solution that does not depend on a priviledged task at run time to open the socket, as you have with persistant tap devices or chardevs like macvtap that can have their persissions set by udev. Arnd Well, we could have a char device with an ioctl that gives you back a socket, or maybe even have it give you back a socket when you open it. Will that make you happy? -- MST -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: vhost-net todo list
On Thursday 17 September 2009, Michael S. Tsirkin wrote: Well, we could have a char device with an ioctl that gives you back a socket, or maybe even have it give you back a socket when you open it. Will that make you happy? Well, that would put is in the exact same spot as the tun/tap driver patch you're working on or my (still unfinished, I need to spend some time on it again) macvtap driver. As I said, either one addresses the problem but is unrelated to the raw socket interface. Arnd -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: vhost-net todo list
On Wednesday 16 September 2009, Michael S. Tsirkin wrote: vhost-net driver projects I still think that list should include - UDP multicast socket support - TCP socket support - raw packet socket support for qemu (from Or Gerlitz) if we have those, plus the tap support that is already on your list, we can use vhost-net as a generic offload for the host networking in qemu. projects involing networking stack - export socket from tap so vhost can use it - working on it now - extend raw sockets to support GSO/checksum offloading, and teach vhost to use that capability [one way to do this: virtio net header support] will allow working with e.g. macvlan One thing I'm planning to work on is bridge support in macvlan, together with VEPA compliant operation, i.e. not sending back multicast frames to the origin. I'll also keep looking into macvtap, though that will be less important once you get the tap socket support running. Arnd -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: vhost-net todo list
On Wed, Sep 16, 2009 at 04:52:40PM +0200, Arnd Bergmann wrote: On Wednesday 16 September 2009, Michael S. Tsirkin wrote: vhost-net driver projects I still think that list should include Yea, why not. Go wild. - UDP multicast socket support - TCP socket support Switch to UDP unicast while we are at it? tunneling raw packets over TCP looks wrong. - raw packet socket support for qemu (from Or Gerlitz) if we have those, plus the tap support that is already on your list, we can use vhost-net as a generic offload for the host networking in qemu. projects involing networking stack - export socket from tap so vhost can use it - working on it now - extend raw sockets to support GSO/checksum offloading, and teach vhost to use that capability [one way to do this: virtio net header support] will allow working with e.g. macvlan One thing I'm planning to work on is bridge support in macvlan, together with VEPA compliant operation, i.e. not sending back multicast frames to the origin. is multicast filtering already there (i.e. only getting frames for groups you want)? I'll also keep looking into macvtap, though that will be less important once you get the tap socket support running. Not sure I see the connection. to get an equivalent to macvtap, what you need is tso etc support in packet sockets. No? Arnd -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: vhost-net todo list
On Wednesday 16 September 2009, Michael S. Tsirkin wrote: On Wed, Sep 16, 2009 at 04:52:40PM +0200, Arnd Bergmann wrote: On Wednesday 16 September 2009, Michael S. Tsirkin wrote: vhost-net driver projects I still think that list should include Yea, why not. Go wild. - UDP multicast socket support - TCP socket support Switch to UDP unicast while we are at it? tunneling raw packets over TCP looks wrong. Well, TCP is what qemu supports right now, that's why I added it to the list. We could add UDP unicast as yet another protocol in both qemu and vhost_net if there is demand for it. The implementation should be trivial based on the existing code paths. One thing I'm planning to work on is bridge support in macvlan, together with VEPA compliant operation, i.e. not sending back multicast frames to the origin. is multicast filtering already there (i.e. only getting frames for groups you want)? No, I think this is less important, because the bridge code also doesn't do this. I'll also keep looking into macvtap, though that will be less important once you get the tap socket support running. Not sure I see the connection. to get an equivalent to macvtap, what you need is tso etc support in packet sockets. No? I'm not worried about tso support here. One of the problems that raw packet sockets have is the requirement for root permissions (e.g. through libvirt). Tap sockets and macvtap both don't have this limitation, so you can use them as a regular user without libvirt. Arnd -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: vhost-net todo list
On Wed, Sep 16, 2009 at 05:08:46PM +0200, Arnd Bergmann wrote: On Wednesday 16 September 2009, Michael S. Tsirkin wrote: On Wed, Sep 16, 2009 at 04:52:40PM +0200, Arnd Bergmann wrote: On Wednesday 16 September 2009, Michael S. Tsirkin wrote: vhost-net driver projects I still think that list should include Yea, why not. Go wild. - UDP multicast socket support - TCP socket support Switch to UDP unicast while we are at it? tunneling raw packets over TCP looks wrong. Well, TCP is what qemu supports right now, that's why I added it to the list. We could add UDP unicast as yet another protocol in both qemu and vhost_net if there is demand for it. The implementation should be trivial based on the existing code paths. One thing I'm planning to work on is bridge support in macvlan, together with VEPA compliant operation, i.e. not sending back multicast frames to the origin. is multicast filtering already there (i.e. only getting frames for groups you want)? No, I think this is less important, because the bridge code also doesn't do this. True, but the reason might be that it is much harder in bridge (you have to snoop multicast registrations). With macvlan you know which multicasts does each device want. I'll also keep looking into macvtap, though that will be less important once you get the tap socket support running. Not sure I see the connection. to get an equivalent to macvtap, what you need is tso etc support in packet sockets. No? I'm not worried about tso support here. One of the problems that raw packet sockets have is the requirement for root permissions (e.g. through libvirt). Tap sockets and macvtap both don't have this limitation, so you can use them as a regular user without libvirt. I don't see a huge difference here. If you are happy with the user being able to bypass filters in host, just give her CAP_NET_RAW capability. It does not have to be root. Arnd -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: vhost-net todo list
On Wednesday 16 September 2009, Michael S. Tsirkin wrote: No, I think this is less important, because the bridge code also doesn't do this. True, but the reason might be that it is much harder in bridge (you have to snoop multicast registrations). With macvlan you know which multicasts does each device want. Right. It shouldn't be hard to do, and I'll probably get to that after the other changes. One of the problems that raw packet sockets have is the requirement for root permissions (e.g. through libvirt). Tap sockets and macvtap both don't have this limitation, so you can use them as a regular user without libvirt. I don't see a huge difference here. If you are happy with the user being able to bypass filters in host, just give her CAP_NET_RAW capability. It does not have to be root. Capabilities are nice in theory, but I've never seen them being used effectively in practice, where it essentially comes down to some SUID wrapper. Also, I might not want to allow the user to open a random random raw socket, but only one on a specific downstream port of a macvlan interface, so I can filter out the data from that respective MAC address in an external switch. That scenario is probably not so relevant for KVM, unless you consider the guest taking over the qemu host process a valid security threat. Arnd -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: vhost-net todo list
On Wed, Sep 16, 2009 at 05:27:25PM +0200, Arnd Bergmann wrote: On Wednesday 16 September 2009, Michael S. Tsirkin wrote: No, I think this is less important, because the bridge code also doesn't do this. True, but the reason might be that it is much harder in bridge (you have to snoop multicast registrations). With macvlan you know which multicasts does each device want. Right. It shouldn't be hard to do, and I'll probably get to that after the other changes. One of the problems that raw packet sockets have is the requirement for root permissions (e.g. through libvirt). Tap sockets and macvtap both don't have this limitation, so you can use them as a regular user without libvirt. I don't see a huge difference here. If you are happy with the user being able to bypass filters in host, just give her CAP_NET_RAW capability. It does not have to be root. Capabilities are nice in theory, but I've never seen them being used effectively in practice, where it essentially comes down to some SUID wrapper. Heh, for tap people seem to just give out write access to it and that's all. Not really different. Also, I might not want to allow the user to open a random random raw socket, but only one on a specific downstream port of a macvlan interface, so I can filter out the data from that respective MAC address in an external switch. I agree. Maybe we can fix that for raw sockets, want me to add it to the list? :) That scenario is probably not so relevant for KVM, unless you consider the guest taking over the qemu host process a valid security threat. Defence in depth is a good thing, anyway. Arnd -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: vhost-net todo list
On 09/16/2009 06:27 PM, Arnd Bergmann wrote: That scenario is probably not so relevant for KVM, unless you consider the guest taking over the qemu host process a valid security threat. It is. We address it by using SCM_RIGHTS for all sensitive operations and selinuxing qemu as tightly as possible. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
