netdev - Re: [PATCH next v2 2/3] ipvlan: Process fragmented multicast frames correctly

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:	Mon, 4 May 2015 15:58:59 -0700
From:	Mahesh Bandewar <maheshb@...gle.com>
To:	David Miller <davem@...emloft.net>
Cc:	linux-netdev <netdev@...r.kernel.org>,
	Eric Dumazet <edumazet@...gle.com>, dcbw@...hat.com
Subject: Re: [PATCH next v2 2/3] ipvlan: Process fragmented multicast frames correctly

On Fri, May 1, 2015 at 6:12 PM, David Miller <davem@...emloft.net> wrote:
> From: Mahesh Bandewar <maheshb@...gle.com>
> Date: Wed, 29 Apr 2015 11:19:18 -0700
>
>> Multicast processing in IPvlan was faulty as is. Eric Dumazet
>> pointed out that fragmented packets won't be processed correctly
>> unless defrag step is introduced.
>>
>> This patch adds the defrag step before driver attempts to process
>> multicast frame(s).
>>
>> Signed-off-by: Mahesh Bandewar <maheshb@...gle.com>
>
> And now you are potentially modifying the geometry of packets that
> traverse ipvlan devices.
>
Yes, that is true but to optimize the fragments processing.

> I am sorry but I am going to put my foot down and not allow another
> instance of this to happen again.  We already have this being done by
> netfilter, and I consider it unacceptable as well as inefficient.
>
Actually this will make the fragments processing more efficient. e.g.
if there are 50 slave devices and we receive 10 fragments, the
duplication will happen for 50*10 = 500 skbs but if the packet is
defragmented, then it's only once per device making it more efficient.

> If a fragmented frame is going to be forwarded by us, defragmenting
> and refragmenting may create a different outgoing packet stream than
> what arrived.  If the outgoing interface's MTU can accomodate the
> incoming frames, this kind of modification is absolutely forbidden.

I understand the concern (after going though Florian Westphal's patch
series) and will take this patch off of this series until matter
settles. Also trying to optimize slow path (fragments) is not very
high on the priority list in any case.

Thanks,
--mahesh..
--
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