lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 11 Feb 2010 08:12:54 +0100 From: Arnd Bergmann <arnd@...db.de> To: Ed Swierk <eswierk@...stanetworks.com> Cc: Sridhar Samudrala <sri@...ibm.com>, netdev@...r.kernel.org Subject: Re: [PATCH 0/3 v4] macvtap driver On Thursday 11 February 2010 01:42:04 Ed Swierk wrote: > On Wed, Feb 10, 2010 at 6:50 AM, Arnd Bergmann <arnd@...db.de> wrote: > > I think we also need to ensure the device doesn't go away, which > > was one of the reasons for the rcu_read_lock_bh() earlier. > > This may be veering far off into the weeds, but I'm wondering if you > considered making macvtap devices behave more like tap devices. > Specifically, the application would open /dev/net/macvtap and send it > an ioctl with the name of the macvtap interface, the name of the lower > interface to attach to, the MAC address, etc; this would cause the > macvtap interface to spring into existence. The macvtap interface > would go away when the application exits or closes the file. No, I never considered this. In fact, this behavior of tun/tap is what makes that driver have really complex lifetime rules (more so than macvtap) and causes all sorts of problems if you want to manage unprivileged users accessing different outgoing interfaces. > The tricky part here would be noticing when the lower interface goes > away, and (ideally) reattaching when an interface with the same name > reappears. The first part is not so hard, the second part I'd rather not do. > I think the advantage of this approach is that it better fits the way > applications like qemu and libvirt use tap interfaces. Unlike the > current approach, however, this wouldn't allow creating a macvtap > interface and keep it around independently of the application using > it. Is it desirable to support this use case? I think it's very useful that you can set up static interfaces and give them to a user (or group) that are then able to use these interfaces without getting any network privileges beyond that. Another reason for having one chardev per interface is to support multiple open files for the same interface. I want to use that as an easy way to support multi-queue NICs. Arnd -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists