netdev - Re: Problems with fragments since gso skb forwarding changes in virtual environment

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:	Tue, 08 Apr 2014 14:24:25 +0200
From:	Tobias Brunner <tobias@...ongswan.org>
To:	Florian Westphal <fw@...len.de>
CC:	netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	Marcelo Ricardo Leitner <mleitner@...hat.com>
Subject: Re: Problems with fragments since gso skb forwarding changes in virtual
 environment

Hi Florian,

> Do I interpret this correctly:
> 
> Host A - br1 - Router R - br2 - Host B
>   Mtu >1500               Mtu 1500
> 
> 1. host A sends GSO packet, DF not set
> 2. packet arrives at R, still GSO packet
> 3. forward on R fragments packet since it won't fit
>    outgoing interface (which is normal virtio ethernet) mtu
> 4. fragmented packets leave R
> 5. fragmented packets arrive on host system (not pictured above) br2
> interface
> 
> 6. packets are being bridged on host system, call_iptables sysctl on
> 7. packets are defragmented by netfilter on host due to call_iptables
> sysctl on
> 8. packets are tossed on host in br_dev_queue_push_xmit because
>    is_skb_forwardable() returns false
> 
> Is that correct?

Exactly.  The MTU is 1500 on all interfaces though.

>> Without the commit, and between A and R even with it (because it only
>> affects forwarding), the skbs are GSO throughout and transmitted from A
>> to B without ever actually being fragmented.
> 
> I see why this change makes it trip over GSO skbs, but I fail to
> see why it would work with larger-than-1500-mtu-and-fragmentation-allowed
> packets being sent from A to B. (or with fragments generated locally
> on R).
> 
> To the host system it should make no difference at all if the fragments
> came into existence in R's forwarding path, or being sent by A, or if
> the fragments were generated locally on R (i.e. ping -s $bignum $hosta
> on R with DF off).

In our test scenarios the packets are UDP and GSO and without the commit
(or between A and R) they travel unchanged between guest and host
kernels without ever touching a physical interface that would actually
cause them to get fragmented (I wasn't aware of this, until I looked
into this issue).

For ICMP it's interesting to note that 'ping -s $bignum $hostb' from A
works even with the commit.  The packet is already fragmented when it
leaves A and these fragments are forwarded properly by the host bridges.
 They are defragmented by the nf_defrag_ipv4 module, but are fragmented
again in br_nf_dev_queue_xmit() because skb->nfct is non-null as pointed
out by you and David.

I tried removing the skb->nfct check, and while that fixes the
forwarding issue on the host, for some reason the UDP socket on B does
not receive the packet (the guest kernel does, even defragments it and
queues it to the socket, but the userland program never receives the
datagram).

Regards,
Tobias

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