[ovs-dev] [PATCH 3/3] datapath: lisp: Use skb rxhash for source port.

Thomas Graf tgraf at redhat.com
Wed Nov 20 09:43:49 UTC 2013


On 11/20/2013 10:14 AM, Jesse Gross wrote:
> On Wed, Nov 20, 2013 at 1:08 AM, Thomas Graf <tgraf at redhat.com> wrote:
>> On 11/19/2013 10:50 PM, Pravin B Shelar wrote:
>>>
>>> Rather than using complete flow hash, we can use skb->rxhash for
>>> calculating source port. Similar calculation is done by vxlan.
>>>
>>> Signed-off-by: Pravin B Shelar <pshelar at nicira.com>
>>> ---
>>>    datapath/vport-lisp.c |    9 +++------
>>>    1 files changed, 3 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/datapath/vport-lisp.c b/datapath/vport-lisp.c
>>> index e4e603f..0938e84 100644
>>> --- a/datapath/vport-lisp.c
>>> +++ b/datapath/vport-lisp.c
>>> @@ -165,16 +165,13 @@ static __be64 instance_id_to_tunnel_id(__u8 *iid)
>>>     */
>>>    static u16 get_src_port(struct sk_buff *skb)
>>>    {
>>> -       int low;
>>> -       int high;
>>>          unsigned int range;
>>> -       struct sw_flow_key *pkt_key = OVS_CB(skb)->pkt_key;
>>> -       u32 hash = jhash2((const u32 *)pkt_key,
>>> -                         sizeof(*pkt_key) / sizeof(u32), 0);
>>> +       int high;
>>> +       int low;
>>>
>>>          inet_get_local_port_range(&low, &high);
>>>          range = (high - low) + 1;
>>> -       return (((u64) hash * range) >> 32) + low;
>>> +       return (((u64) skb_get_rxhash(skb) * range) >> 32) + low;
>>>    }
>>>
>>>    static void lisp_build_header(const struct vport *vport,
>>>
>>
>> I might be missing something but what about the rxhash == 0 case?
>>
>> VXLAN does:
>>          hash = skb_get_rxhash(skb);
>>          if (!hash)
>>                  hash = jhash(skb->data, 2 * ETH_ALEN,
>>                               (__force u32) skb->protocol);
>>
>> Shouldn't we hash the pkt_key then?
>
> LISP is an L3 protocol rather than L2 like VXLAN so we're guaranteed
> to have at least IP addresses to hash in skb_get_rxhash().

Right, unless skb_flow_dissect() fails which I think could be triggered
when an invalid GRE header is encapsulated on top of IP inside LISP.
Basically any header violation caught by skb_flow_dissect() that is not
caught by the flow extraction. An attacker could use such packets to
force unhashed source ports to overload a load balancer.

Same could happen if the RX NIC RSS results in 0, i.e.
(skb->l4_rxhash && !skb->rxhash)

VXLAN would handle these fine right now.



More information about the dev mailing list