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: <20211103093843.200fc421@kicinski-fedora-PC1C0HJN>
Date:   Wed, 3 Nov 2021 09:38:43 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Vladimir Oltean <vladimir.oltean@....com>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Nikolay Aleksandrov <nikolay@...dia.com>,
        Jiri Pirko <jiri@...dia.com>, Ido Schimmel <idosch@...dia.com>,
        Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>
Subject: Re: Is it ok for switch TCAMs to depend on the bridge state?

On Tue, 2 Nov 2021 11:03:53 +0000 Vladimir Oltean wrote:
> I don't have a clear picture in my mind about what is wrong. An airplane
> viewer might argue that the TCAM should be completely separate from the
> bridging service, but I'm not completely sure that this can be achieved
> in the aforementioned case with VLAN rewriting on ingress and on egress,
> it would seem more natural for these features to operate on the
> classified VLAN (which again, depends on VLAN awareness being turned on).
> Alternatively, one might argue that the deletion of a bridge interface
> should be vetoed, and so should the removal of a port from a bridge.
> But that is quite complicated, and doesn't answer questions such as
> "what should you do when you reboot".
> Alternatively, one might say that letting the user remove TCAM
> dependencies from the bridging service is fine, but the driver should
> have a way to also unoffload the tc-flower keys as long as the
> requirements are not satisfied. I think this is also difficult to
> implement.

Some random thoughts which may be completely nonsensical.

I thought we do have a way of indicating that flower rules are no
longer offloaded because tunnel rules need neigh to be resolved, 
but looking at the code it seems we only report some semblance of
offload status as part of stats.

For port removal maybe we can add a callback just for vetoing in case
the operation originates from user space?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ