netdev - Re: [RFC PATCH] macvlan: Introduce a PASSTHRU mode to takeover the underlying device

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 27 Oct 2010 16:05:29 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Sridhar Samudrala <sri@...ibm.com>
Cc:	kaber@...sh.net, netdev <netdev@...r.kernel.org>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>
Subject: Re: [RFC PATCH] macvlan: Introduce a PASSTHRU mode to takeover the underlying device

On Wednesday 27 October 2010, Sridhar Samudrala wrote:
> With the current default macvtap mode, a KVM guest using virtio with 
> macvtap backend has the following limitations.
> - cannot change/add a mac address on the guest virtio-net
> - cannot create a vlan device on the guest virtio-net
> - cannot enable promiscuous mode on guest virtio-net
> 
> This patch introduces a new mode called 'passthru' when creating a 
> macvlan device which allows takeover of the underlying device and 
> passing it to a guest using virtio with macvtap backend.
> 
> Only one macvlan device is allowed in passthru mode and it inherits
> the mac address from the underlying device and sets it in promiscuous 
> mode to receive and forward all the packets.

Interesting approach. It somewhat stretches the definition of the
macvlan concept, but it does sound useful to have.

I was thinking about adding a new tap frontend driver that could
share some code with macvtap and do only the takeover but not
use macvlan as a base. I believe that would be a cleaner abstraction,
but your code has two advantages in that the implementation is much
simpler and that it can share a fair amount of the infrastructure
that we're putting into qemu/libvirt/etc.

	Arnd

PS: Please add a Signed-off-by: line when sending a patch, even for
discussion.
--
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