netdev - Re: [PATCH] net br_netlink.c:y allow non "disabled" state for !netif_oper

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: <Y25JpVOSc6mh0cx8@lunn.ch>
Date:   Fri, 11 Nov 2022 14:09:57 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Rodolfo Giometti <giometti@...eenne.com>
Cc:     netdev@...r.kernel.org, Roopa Prabhu <roopa@...dia.com>,
        Nikolay Aleksandrov <razor@...ckwall.org>,
        Stephen Hemminger <shemminger@...l.org>,
        Flavio Leitner <fbl@...hat.com>,
        "David S . Miller" <davem@...emloft.net>
Subject: Re: [PATCH] net br_netlink.c:y allow non "disabled" state for
 !netif_oper_up() links

> > I also
> > wonder what the hardware drivers do? Since this is a change in
> > behaviour, they might not actually do anything.
> 
> For instance Marvell switches just set the state (see
> linux/drivers/net/dsa/mv88e6xxx/port.c) without checking for carrier status:

Yes, that was one i checked myself. I think i remember reviewing a DSA
driver which did not have a mechanism to disable a port, other than
the STP state. So there is a danger the mac_down() call is going to
change the STP state, and the mac_up() call will change it again.

> Yes, of course we can do it but (in case of MRP) the state machine must be
> altered in several points and, again, why the kernel should force such
> behaviour (i.e. introducing a policy) when drivers just don't consider it
> (see the above example).
> 
> The kernel should implement mechanisms while all policies should be into user space.

While i agree the policy should not be in the kernel, you have history
against you. Since this was never a requirement, and on first
mentioning it, it seems like an odd requirement, there is no guarantee
it will actually work for all drivers. So either you have to:

1) Say some kernel drivers are probably broken, will do horrible
   things to your network instead of being redundant, test it well
   before deploying.

2) Monitor for the link up event, and set the STP state as required.

The in kernel bridge/STP code takes this second approach, which again
reinforces the fact that because drivers never needed to support this,
some probably don't.

     Andrew