linux-kernel - Re: [PATCH 3.2 085/115] veth: don???t modify ip_summed; doing so treats packets with bad checksums as good.

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:	Fri, 13 May 2016 09:57:19 -0700
From:	Ben Greear <greearb@...delatech.com>
To:	"David S. Miller" <davem@...emloft.net>
Cc:	Willy Tarreau <w@....eu>, Vijay Pandurangan <vijayp@...ayp.ca>,
	Tom Herbert <tom@...bertland.com>,
	Ben Hutchings <ben@...adent.org.uk>,
	Sabrina Dubroca <sd@...asysnail.net>,
	Hannes Frederic Sowa <hannes@...essinduktion.org>,
	LKML <linux-kernel@...r.kernel.org>, stable@...r.kernel.org,
	akpm@...ux-foundation.org, Cong Wang <cwang@...pensource.com>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	Evan Jones <ej@...njones.ca>,
	Nicolas Dichtel <nicolas.dichtel@...nd.com>,
	Phil Sutter <phil@....cc>,
	Toshiaki Makita <makita.toshiaki@....ntt.co.jp>,
	Cong Wang <xiyou.wangcong@...il.com>
Subject: Re: [PATCH 3.2 085/115] veth: don???t modify ip_summed; doing so
 treats packets with bad checksums as good.

Mr Miller:

How do you feel about a new socket-option to allow a socket to
request the old veth behaviour?

Thanks,
Ben

On 04/30/2016 10:30 PM, Willy Tarreau wrote:
> On Sat, Apr 30, 2016 at 03:43:51PM -0700, Ben Greear wrote:
>> On 04/30/2016 03:01 PM, Vijay Pandurangan wrote:
>>> Consider:
>>>
>>> - App A  sends out corrupt packets 50% of the time and discards inbound data.
> (...)
>> How can you make a generic app C know how to do this?  The path could be,
>> for instance:
>>
>> eth0 <-> user-space-A <-> vethA <-> vethB <-> { kernel routing logic } <-> vethC <-> vethD <-> appC
>>
>> There are no sockets on vethB, but it does need to have special behaviour to elide
>> csums.  Even if appC is hacked to know how to twiddle some thing on it's veth port,
>> mucking with vethD will have no effect on vethB.
>>
>> With regard to your example above, why would A corrupt packets?  My guess:
>>
>> 1)  It has bugs (so, fix the bugs, it could equally create incorrect data with proper checksums,
>>      so just enabling checksumming adds no useful protection.)
>
> I agree with Ben here, what he needs is the ability for userspace to be
> trusted when *forwarding* a packet. Ideally you'd only want to receive
> the csum status per packet on the packet socket and pass the same value
> on the vethA interface, with this status being kept when the packet
> reaches vethB.
>
> If A purposely corrupts packet, it's A's problem. It's similar to designing
> a NIC which intentionally corrupts packets and reports "checksum good".
>
> The real issue is that in order to do things right, the userspace bridge
> (here, "A") would really need to pass this status. In Ben's case as he
> says, bad checksum packets are dropped before reaching A, so that
> simplifies the process quite a bit and that might be what causes some
> confusion, but ideally we'd rather have recvmsg() and sendmsg() with
> these flags.
>
> I faced the exact same issue 3 years ago when playing with netmap, it was
> slow as hell because it would lose all checksum information when packets
> were passing through userland, resulting in GRO/GSO etc being disabled,
> and had to modify it to let userland preserve it. That's especially
> important when you have to deal with possibly corrupted packets not yet
> detected in the chain because the NIC did not validate their checksums.
>
> Willy
>


-- 
Ben Greear <greearb@...delatech.com>
Candela Technologies Inc  http://www.candelatech.com