netdev - Re: [PATCH net-next 3/6] geneve: Add support to collect tunnel metadata.

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] [day] [month] [year] [list]

Message-ID: <CAEP_g=-APpY2QprRTiRNq1Ptfjut_TeUNuQy=+HDXxm7HX=y4w@mail.gmail.com>
Date:	Thu, 13 Aug 2015 14:13:21 -0700
From:	Jesse Gross <jesse@...ira.com>
To:	Pravin Shelar <pshelar@...ira.com>
Cc:	netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 3/6] geneve: Add support to collect tunnel metadata.

On Wed, Aug 12, 2015 at 4:08 PM, Pravin Shelar <pshelar@...ira.com> wrote:
> On Wed, Aug 12, 2015 at 1:53 PM, Jesse Gross <jesse@...ira.com> wrote:
>> On Tue, Aug 11, 2015 at 10:17 PM, Pravin B Shelar <pshelar@...ira.com> wrote:
>>> diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
>>> index 5e9bab8..a463383 100644
>>> --- a/drivers/net/geneve.c
>>> +++ b/drivers/net/geneve.c
>>> +static struct geneve_dev *geneve_lookup(struct geneve_net *gn,
>>> +                                       struct iphdr *iph,
>>> +                                       struct genevehdr *gnvh)
>>>  {
>>> -       struct genevehdr *gnvh = geneve_hdr(skb);
>>> -       struct geneve_dev *dummy, *geneve = NULL;
>>> -       struct geneve_net *gn;
>>> -       struct iphdr *iph = NULL;
>>> -       struct pcpu_sw_netstats *stats;
>>>         struct hlist_head *vni_list_head;
>>> -       int err = 0;
>>> +       struct geneve_dev *geneve;
>>>         __u32 hash;
>>>
>>> -       iph = ip_hdr(skb); /* Still outer IP header... */
>>> -
>>> -       gn = gs->rcv_data;
>>> -
>>>         /* Find the device for this VNI */
>>>         hash = geneve_net_vni_hash(gnvh->vni);
>>>         vni_list_head = &gn->vni_list[hash];
>>> -       hlist_for_each_entry_rcu(dummy, vni_list_head, hlist) {
>>> -               if (!memcmp(gnvh->vni, dummy->vni, sizeof(dummy->vni)) &&
>>> -                   iph->saddr == dummy->remote.sin_addr.s_addr) {
>>> -                       geneve = dummy;
>>> -                       break;
>>> +       hlist_for_each_entry_rcu(geneve, vni_list_head, hlist) {
>>> +               if (!memcmp(gnvh->vni, geneve->vni, sizeof(geneve->vni)) &&
>>> +                   iph->saddr == geneve->remote.sin_addr.s_addr) {
>>> +                       return geneve;
>>>                 }
>>>         }
>>> +
>>> +       return rcu_dereference(gn->collect_md_tun);
>>> +}
>>
>> I think this operates differently from VXLAN (and GRE I believe) where
>> you can't have tunnels based on the VNI overlapping the
>> collect_md_tun. VXLAN is nice because it can go straight from the
>> socket to collecting metadata without having to an additional lookup
>> that doesn't give any additional information and it seems a little
>> simpler because we don't need to keep track of a flow-based device.
>> However, at the very least the behavior should be consistent.
>>
> This is how GRE works. But I can check for flow based device first to
> keep it consistent with vxlan.

Besides the lookup order, VXLAN will also disallow this configuration
at creation time.
--
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