netdev - Re: [PATCH 4/5] virtio_net: Add a MAC filter table

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]

Message-Id: <200901282115.14083.rusty@rustcorp.com.au>
Date:	Wed, 28 Jan 2009 21:15:13 +1030
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	Alex Williamson <alex.williamson@...com>
Cc:	netdev@...r.kernel.org, markmc@...hat.com, kvm@...r.kernel.org
Subject: Re: [PATCH 4/5] virtio_net: Add a MAC filter table

On Tuesday 27 January 2009 14:08:02 Alex Williamson wrote:
> Hi Rusty,
> 
> On Tue, 2009-01-27 at 13:00 +1030, Rusty Russell wrote:
> > On Saturday 17 January 2009 07:43:34 Alex Williamson wrote:
> > > As with most real hardware, unicast addresses have priority in
> > 
> > > the filter table so we can avoid enabling full promiscuous
> > 
> > > until both unicast and multicast address overflow.
> > 
> > Why not pretend to have infinite, and have the host turn promisc on
> > when *it*
> > 
> > decides? Skip the alloc call, and just use a feature bit like
> > everything else?
> 
> I suppose it's just a matter of where do you want to add the smarts and
> the tune-ability.  Since we can't actually have an infinite table and an
> array implementation seems to make sense from an efficiency standpoint,
> it needs to be defined by someone to be a fixed size before we start
> using it.  I was hoping the guest driver might have a better idea how it
> plans to use the filter table and that there'd be some benefit to having
> that handshake happen between the driver and the backend.  The module
> parameter fell out of this and seems rather convenient.
> 
> I could pursue this is you like, but I'm not sure of the benefit,
> particularly if we want to give the user some control of the size of the
> actual table.  Thoughts?  Thanks for the comments,

I don't think the either-or case is real.  Say the user decides they want a table of 1000000 entries.  And the backend says "no way, I have a 16 array"?  Currently you get nothing.

I guess your qemu code does dynamic allocation.  But I'm sure you put a limit in there, right? :)

We don't want some complex negotiation, and I don't think the guest has any more clue than the host, nor can do much about it.

Cheers,
Rusty.
--
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