netdev - Re: [RFC] vxlan: convert remote list to list

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]

Message-ID: <OFB0EFD290.FD0EF659-ON85257B7F.00733AF7-85257B7F.0077A32C@us.ibm.com>
Date:	Mon, 3 Jun 2013 17:46:46 -0400
From:	David Stevens <dlstevens@...ibm.com>
To:	Stephen Hemminger <stephen@...workplumber.org>
Cc:	Mike Rapoport <mike.rapoport@...ellosystems.com>,
	netdev@...r.kernel.org, netdev-owner@...r.kernel.org,
	Thomas Graf <tgraf@...g.ch>
Subject: Re: [RFC] vxlan: convert remote list to list_rcu

From: Stephen Hemminger <stephen@...workplumber.org>

> 
> Just being safe. need to audit to make sure not possible for all
> destinations to be removed from FDB entry via netlink.

        In the original code, you can't delete destinations at all.
Because the netlink API only had fdb-entry-level operations, you
can add with the NLM_F_APPEND flag to add new destinations to
existing entries (it's an "add/create" if it didn't exist, and it
appends the new dest if it did exist and has NLM_F_APPEND set),
but an fdb delete deletes the entire fdb entry, and all destinations.
So, you can't delete individual destinations, you can only delete
all of them and rebuild it with appends to not include the entry
you don't want.
        This was for compatibility rather than adding new add/del of
destinations within an fdb, it uses the existing fdb add/del and
the existing exclusive/append flag. Deleting individual destinations
from an fdb entry would require extensions for the generic fdb
management, or a separate set of netlink handlers.

> > 
> > Again, if rdst == NULL, why are we sending anything? It should never
> > happen, so should be an error case if you check at all, shouldn't it?
> 
> It maybe possible to create or modify existing fdb entry so no 
destinatons
> left.

        It shouldn't be (by design). The only way you can shorten an fdb
entry's destination list is by deleting it and rebuilding it with fewer
entries. And all fdb_add's require an NDA_DST, though that can be
0.0.0.0.
 
> > This ignores the return value of vxlan_xmit_one(); the original
> > code returns an error if any of the destinations fail, while this
> > code ignores errors for all but the last destination.
> 
> Return value doesn't really matter here anyway, and certainly not
> in the fanout case.

        My intention in the code was to count any loss in the multiple
destinations as a "drop", for the purposes of drawing attention to
an admin. This new code reports only the sate of the last destination
and ignores any errors from all the other destinations-- I don't
agree with that. If it didn't work perfectly as intended, it should
show up in stats for admin investigation.

But i don't think any of this fdb code relates to the default
destination directly, since the generic fdb code does not support
default, or any other aggregate matching. VXLAN can define the
netlink API for default destinations without affecting anything
else, because it is already a per-device feature.

                                                        +-DLS

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