netdev - Re: [PATCH] ipvlan: fix up broadcast MAC filtering for ARP and DHCP

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: <1428502335.12988.1.camel@redhat.com>
Date:	Wed, 08 Apr 2015 09:12:15 -0500
From:	Dan Williams <dcbw@...hat.com>
To:	David Laight <David.Laight@...LAB.COM>
Cc:	Mahesh Bandewar <maheshb@...gle.com>,
	linux-netdev <netdev@...r.kernel.org>,
	"jbenc@...hat.com" <jbenc@...hat.com>
Subject: Re: [PATCH] ipvlan: fix up broadcast MAC filtering for ARP and DHCP

On Wed, 2015-04-08 at 09:37 +0000, David Laight wrote:
> From: Dan Williams
> ...
> > > Probably something similar where turn on the broadcast bit and wait
> > > for the interface to get configured (2 min timer) and at the expiry
> > > decide what is to be done about braodcast bit. If the addresses
> > > configured are all IPv6, then eliminate it and if any of them are IPv4
> > > then don't change it. In this case no special casing nor snooping is
> > > required and this should work for dual-stack scenario as well.
> > 
> > This does not work for the case where, after configuring, the DHCPv4
> > address lease expires and the IPv4 address is removed, and then DHCPv4
> > is started again.  Possibly because the DHCP server was gone for a short
> > time.  The only way to handle that is to snoop again.
> > 
> > Reaching for maximum performance is great, but if that is done by
> > ignoring/breaking a whole class of normal use-cases, I don't think
> > that's reasonable.  It's like saying "gee, I'd love UDP to be faster, so
> > I'll remove anything TCP-related in the kernel".
> > 
> > Also, I don't think the snooping is as bad for performance as you may
> > think.  The only relevant issue here is L2 + IPv6-only, and in that case
> > it's 4 extra compares (dhcp4_seen, ipv4cnt, lyr3h, and addr_type) for
> > the external case.  How much is that really going to slow things down,
> > versus breaking a huge part of IPv4 address configuration?
> 
> How much performance do you really gain from disabling broadcasts in hardware?
> (Unless your network has massive broadcast storms - which are a different problem).
> I can imagine it helping a low power device stay idle.

I'm not sure what metrics the decision to have a broadcast filter in
ipvlan was based on since I'm just trying to fix some bugs, but I assume
Mahesh has the answer to that?

Dan

> For DHCP you have bigger issues.
> All the versions of the dhcp client I've seen use the bpf interface for
> receive traffic (even once started) so you get the cost of a clone
> of every received packet.
> 
> 	David
> 
> NrybXǧv^)޺{.n+z^)w*.jg.ݢj/zޖ2ޙ&)ߡa.Gh.j:+vw٥


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