linux-kernel - Re: [PATCH net-next] macvlan: delay the header check for dodgy packets into lower device

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:	Thu, 27 Nov 2014 13:14:28 +0800
From:	Jason Wang <jasowang@...hat.com>
To:	David Miller <davem@...emloft.net>
CC:	kaber@...sh.net, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, mst@...hat.com, vyasevic@...hat.com
Subject: Re: [PATCH net-next] macvlan: delay the header check for dodgy packets
 into lower device



On 11/27/2014 04:37 AM, David Miller wrote:
> From: Jason Wang <jasowang@...hat.com>
> Date: Wed, 26 Nov 2014 17:21:14 +0800
>
>> We do header check twice for a dodgy packet. One is done before
>> macvlan_start_xmit(), another is done before lower device's
>> ndo_start_xmit(). The first one seems redundant so this patch tries to
>> delay header check until a packet reaches its lower device (or macvtap)
>> through always enabling NETIF_F_GSO_ROBUST for macvlan device.
>>
>> Cc: Patrick McHardy <kaber@...sh.net>
>> Signed-off-by: Jason Wang <jasowang@...hat.com>
>
> Hmmm, it's the idea that if we have a dodgy packet, we want to
> notice that as early as possible in the packet processing path?
>

Not late even with this patch. The check will be done immediately after 
macvlan passing a packet to lower device which should be sufficient.

For good packets, this patch saves one time of header checking. For bad 
packets, this patch just lets the dropping happens during the validation 
before ndo_start_xmit() of lower device.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/