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>] [day] [month] [year] [list]
Date:	Tue, 2 Nov 2010 20:42:57 +0200
From:	"Michael S. Tsirkin" <mst@...hat.com>
To:	Sridhar Samudrala <sri@...ibm.com>
Cc:	kaber@...sh.net, Arnd Bergmann <arnd@...db.de>,
	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 Tue, Nov 02, 2010 at 11:19:13AM -0700, Sridhar Samudrala wrote:
> On Mon, 2010-11-01 at 10:28 +0200, Michael S. Tsirkin wrote:
> 
>     On Tue, Oct 26, 2010 at 03:19:38PM -0700, 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.
>     >
>     > Thanks
>     > Sridhar
> 
>     One concern with promisc mode is that for the common case,
>     which is a single mac and no vlans, we will be getting
>     extra packets that will get dropped in userspace/guest
>     as compared to the case where same mac is programmed
>     in hardware and by guest.
> 
> In the tap/bridge model also, the external i/f is put in promiscuous mode and
> the
> bridge does the filtering of extra packets.

Yes but
1. that is much cheaper than passing them all the way up to the guest.
2. it's pretty painful for management to have to decide between
   features and speed. Better give them both :)

>     We could let userspace supply a list of mac/vlan addresses through
>     an ioctl on macvtap, and then
>     1. for a single mac, program it in hardware
>     2. for other configurations, set promisc mode
> 
>     tun already has TUNSETTXFILTER which might come in handy here.
>     We don't pass in vlans with the filter now but maybe we should.
>     How does this sound?
> 
> I guess this can be done. But i am not sure if we can extend the existing
> TUNSETTXFILTER
> to support vlans too. we may need a new ioctl.
> 
> Thanks
> Sridhar

OK. Maybe add it to tap too.

-- 
MST
--
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