netdev - Re: [PATCH net-next v2 00/11] net: Convert vrf to tx hook

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 10 Sep 2016 23:13:17 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     dsa@...ulusnetworks.com
Cc:     netdev@...r.kernel.org, shm@...ulusnetworks.com
Subject: Re: [PATCH net-next v2 00/11] net: Convert vrf to tx hook

From: David Ahern <dsa@...ulusnetworks.com>
Date: Sat, 10 Sep 2016 12:09:51 -0700

> The motivation for this series is that ICMP Unreachable - Fragmentation
> Needed packets are not handled properly for VRFs. Specifically, the
> FIB lookup in __ip_rt_update_pmtu fails so no nexthop exception is
> created with the reduced MTU. As a result connections stall if packets
> larger than the smallest MTU in the path are generated.
> 
> While investigating that problem I also noticed that the MSS for all
> connections in a VRF is based on the VRF device's MTU and not the
> route the packets ultimately go through. VRF currently uses a dst
> to direct packets to the device. The first FIB lookup returns this dst
> and then the lookup in the VRF driver gets the actual output route. A
> side effect of this design is that the VRF dst is cached on sockets
> and then used for calculations like the MSS.
> 
> This series fixes this problem by removing the hook in the FIB lookups
> that returns the dst pointing to the VRF device to the VRF and always
> doing the actual FIB lookup. This allows the real dst to be used
> throughout the stack (for example the MSS). Packets are diverted to
> the VRF device on Tx using an l3mdev hook in the output path similar to
> to what is done for Rx. The end result is a simpler implementation for
> VRF with fewer intrusions into the network stack and symmetrical packet
> handling for Rx and Tx paths.
 ...

Series applied, thanks David.