linux-kernel - Re: [PATCH net-next v2 06/12] net: vxlan: make vxlan_set

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: <CADxym3aH_tH7Kq2jXqKt+4owp85nfELdPBJMapG2mwHWN8k98Q@mail.gmail.com>
Date: Wed, 4 Sep 2024 09:59:20 +0800
From: Menglong Dong <menglong8.dong@...il.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: idosch@...dia.com, davem@...emloft.net, edumazet@...gle.com, 
	pabeni@...hat.com, dsahern@...nel.org, dongml2@...natelecom.cn, 
	amcohen@...dia.com, gnault@...hat.com, bpoirier@...dia.com, 
	b.galvani@...il.com, razor@...ckwall.org, petrm@...dia.com, 
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH net-next v2 06/12] net: vxlan: make vxlan_set_mac() return
 drop reasons

On Tue, Sep 3, 2024 at 9:12 AM Jakub Kicinski <kuba@...nel.org> wrote:
>
> On Sun, 1 Sep 2024 20:47:27 +0800 Menglong Dong wrote:
> > > > @@ -1620,7 +1620,7 @@ static bool vxlan_set_mac(struct vxlan_dev *vxlan,
> > > >
> > > >       /* Ignore packet loops (and multicast echo) */
> > > >       if (ether_addr_equal(eth_hdr(skb)->h_source, vxlan->dev->dev_addr))
> > > > -             return false;
> > > > +             return (u32)VXLAN_DROP_INVALID_SMAC;
> > >
> > > It's the MAC address of the local interface, not just invalid...
> > >
> >
> > Yeah, my mistake. It seems that we need to add a
> > VXLAN_DROP_LOOP_SMAC here? I'm not sure if it is worth here,
> > or can we reuse VXLAN_DROP_INVALID_SMAC here too?
>
> Could you take a look at the bridge code and see if it has similar
> checks? Learning the addresses and dropping frames which don't match
> static FDB entries seem like fairly normal L2 switching drop reasons.
> Perhaps we could add these as non-VXLAN specific?
>

Yeah, I'll have a look at that part.

> The subsystem reason API was added for wireless, because wireless
> folks had their own encoding, and they have their own development
> tree (we don't merge their patches directly into net-next).
> I keep thinking that we should add the VXLAN reason to the "core"
> group rather than creating a subsystem..
>

I'm hesitant about this in the beginning too, as VXLAN is a standard
tunnel protocol. And I'm still hesitant now, should I add them to the "core"?
which will make things simpler.

Enn......I'll add them to the "core" in the next version, and let's see
if it is better.

> > > >       /* Get address from the outer IP header */
> > > >       if (vxlan_get_sk_family(vs) == AF_INET) {
> > > > @@ -1635,9 +1635,9 @@ static bool vxlan_set_mac(struct vxlan_dev *vxlan,
> > > >
> > > >       if ((vxlan->cfg.flags & VXLAN_F_LEARN) &&
> > > >           vxlan_snoop(skb->dev, &saddr, eth_hdr(skb)->h_source, ifindex, vni))
> > > > -             return false;
> > > > +             return (u32)VXLAN_DROP_ENTRY_EXISTS;
> > >
> > > ... because it's vxlan_snoop() that checks:
> > >
> > >         if (!is_valid_ether_addr(src_mac))
> >
> > It seems that we need to make vxlan_snoop() return skb drop reasons
> > too, and we need to add a new patch, which makes this series too many
> > patches. Any  advice?
>
> You could save some indentation by inverting the condition:
>
>         if (!(vxlan->cfg.flags & VXLAN_F_LEARN))
>                 return (u32)SKB_NOT_DROPPED_YET;
>
>         return vxlan_snoop(skb->dev, &saddr, eth_hdr(skb)->h_source, ifindex, vni);
>
> But yes, I don't see a better way than having vxlan_snoop() return a
> reason code :(
>
> The patch limit count is 15, 12 is our preferred number but you can go
> higher if it helps the clarity of the series.

Okay! I feel much better with your words :/

Thanks!
Menglong Dong