netdev - [question] bonding: should assert dormant for active protocols like LACP?

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

Date:   Tue, 17 May 2022 17:17:19 -0400
From:   Jonathan Toppins <jtoppins@...hat.com>
To:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Cc:     Jay Vosburgh <j.vosburgh@...il.com>,
        Veaceslav Falico <vfalico@...il.com>,
        Andy Gospodarek <andy@...yhouse.net>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>
Subject: [question] bonding: should assert dormant for active protocols like
 LACP?

So running the following script:

--%<-----
  ip link add name link-bond0 type veth peer name link-end0
  ip link add bond0 type bond mode 4 miimon 100
  ip link set link-bond0 master bond0 down
  ip netns add n1
  ip link set link-end0 netns n1 up
  ip link set bond0 up
  cat /sys/class/net/bond0/bonding/ad_partner_mac
  cat /sys/class/net/bond0/operstate
--%<-----

The bond reports its operstate to be "up" even though the bond will 
never be able to establish an LACP partner. Should bonding for active 
protocols, LACP, assert dormant[0] until the protocol has established 
and frames actually are passed?

Having a predictable operstate where up actually means frames will 
attempt to be delivered would make management applications, f.e. Network 
Manager, easier to write. I have developers asking me what detailed 
states for LACP should they be looking for to determine when an LACP 
bond is "up". This seems like an incorrect implementation of operstate 
and RFC2863 3.1.12.

Does anyone see why this would be a bad idea?

-Jon

[0] Documentation/networking/operstates.rst