netdev - Re: [PATCH net-next 0/5] net: Extend address label support

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: <20230313151028.78fdfec6@kernel.org>
Date:   Mon, 13 Mar 2023 15:10:28 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Petr Machata <petrm@...dia.com>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Paolo Abeni <pabeni@...hat.com>, <netdev@...r.kernel.org>,
        David Ahern <dsahern@...nel.org>,
        Shuah Khan <shuah@...nel.org>,
        Ido Schimmel <idosch@...dia.com>, <mlxsw@...dia.com>
Subject: Re: [PATCH net-next 0/5] net: Extend address label support

On Mon, 13 Mar 2023 14:26:56 +0100 Petr Machata wrote:
> > Feels a bit like we're missing motivation for this change.
> > I thought address labels were legacy cruft.  
> 
> The immutability and lack of IPv6 support is seriously limiting, so the
> fact nobody is using this is not that surprising.
> 
> > Also the usual concern about allowing to change things is that some
> > user space will assume it's immutable. The label could until this 
> > set be used as part of a stable key, right?  
> 
> Maybe. But to change a label, you need to be an admin, so yeah, you can
> screw things up if you want to. You could e.g. delete the address
> outright. In the end it should be on me as an admin to run a stack that
> is not stumbling over itself.

I haven't seen that caveat under the "no uAPI-visible regressions"
rule book...  Have you done a github grep for uses of this attr?
I'm guessing that indeed nobody will notice.

> As for the motivation: the use case we are eying in particular is
> advertisement of MLAG anycast addresses. One label would be used to mark
> anycast addresses if they shouldn't be advertised by the routing stack
> yet, a different label for those that can be advertised. Which labels
> mean what would be a protocol between the two daemons involved.

Hm. I see.

> Other userspace stacks might use this to their own ends to annotate sets
> of addresses according to their needs. Like they can today, if the
> sets only involve IPv4 addresses that never migrate from set to set :)

I suspect we may have skipped the feature in v6 for two reasons 
(1) it had no modern use and (2) address label in IPv6 means
the precedence value in address selection, doesn't it?