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: <CAF2d9jgU44Q6ij4JvCe2mtP-4+AxLyMT_7X=QNhEnJZjSMxtCQ@mail.gmail.com>
Date:	Wed, 8 Apr 2015 18:08:14 -0700
From:	Mahesh Bandewar <maheshb@...gle.com>
To:	David Laight <David.Laight@...lab.com>
Cc:	Dan Williams <dcbw@...hat.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, Apr 8, 2015 at 2:37 AM, David Laight <David.Laight@...lab.com> 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.
>
IPvlan is a virtual driver and is enabling / disabling broadcast on
these virtual links. So N virtual links mean N*clone and that's the
cost.

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