netdev - Re: [PATCH RFC 0/7] net: bridge: cfm: Add support for Connectivity Fault Management(CFM)

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]

Date:   Mon, 7 Sep 2020 13:56:20 +0000
From:   Nikolay Aleksandrov <nikolay@...dia.com>
To:     "stephen@...workplumber.org" <stephen@...workplumber.org>,
        "horatiu.vultur@...rochip.com" <horatiu.vultur@...rochip.com>
CC:     "bridge@...ts.linux-foundation.org" 
        <bridge@...ts.linux-foundation.org>,
        "henrik.bjoernlund@...rochip.com" <henrik.bjoernlund@...rochip.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "jiri@...lanox.com" <jiri@...lanox.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Roopa Prabhu <roopa@...dia.com>,
        "idosch@...lanox.com" <idosch@...lanox.com>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "UNGLinuxDriver@...rochip.com" <UNGLinuxDriver@...rochip.com>
Subject: Re: [PATCH RFC 0/7] net: bridge: cfm: Add support for Connectivity
 Fault Management(CFM)

On Sun, 2020-09-06 at 20:21 +0200, Horatiu Vultur wrote:
> The 09/04/2020 15:44, Stephen Hemminger wrote:
> > On Fri, 4 Sep 2020 09:15:20 +0000
> > Henrik Bjoernlund <henrik.bjoernlund@...rochip.com> wrote:
> > 
> > > Connectivity Fault Management (CFM) is defined in 802.1Q section 12.14.
> > > 
> > > 
[snip]
> > > Currently this 'cfm' and 'cfm_server' programs are standalone placed in a
> > > cfm repository https://github.com/microchip-ung/cfm but it is considered
> > > to integrate this into 'iproute2'.
> > > 
> > > Reviewed-by: Horatiu Vultur  <horatiu.vultur@...rochip.com>
> > > Signed-off-by: Henrik Bjoernlund  <henrik.bjoernlund@...rochip.com>
> 
> Hi Stephen,
> 
> > Could this be done in userspace? It is a control plane protocol.
> > Could it be done by using eBPF?
> 
> I might be able to answer this. We have not considered this approach of
> using eBPF. Because we want actually to push this in HW extending
> switchdev API. I know that this series doesn't cover the switchdev part
> but we posted like this because we wanted to get some feedback from
> community. We had a similar approach for MRP, where we extended the
> bridge and switchdev API, so we tought that is the way to go forward.
> 
> Regarding eBPF, I can't say that it would work or not because I lack
> knowledge in this.
> 
> > Adding more code in bridge impacts a large number of users of Linux distros.
> > It creates bloat and potential security vulnerabilities.

Hi,
I also had the same initial thought - this really doesn't seem to affect the
bridge in any way, it's only collecting and transmitting information. I get
that you'd like to use the bridge as a passthrough device to switchdev to
program your hw, could you share what would be offloaded more specifically ?

All you do - snooping and blocking these packets can easily be done from user-
space with the help of ebtables, but since we need to have a software
implementation/fallback of anything being offloaded via switchdev we might need
this after all, I'd just prefer to push as much as possible to user-space.

I plan to review the individual patches tomorrow.

Thanks,
 Nik