Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 1 Jul 2022 20:00:45 +0300
From:   Ido Schimmel <idosch@nvidia.com>
To:     Hans S <schultz.hans@gmail.com>
Cc:     "David S. Miller" <davem@davemloft.net>,
        Jakub Kicinski <kuba@kernel.org>, netdev@vger.kernel.org,
        Andrew Lunn <andrew@lunn.ch>,
        Vivien Didelot <vivien.didelot@gmail.com>,
        Florian Fainelli <f.fainelli@gmail.com>,
        Vladimir Oltean <olteanv@gmail.com>,
        Eric Dumazet <edumazet@google.com>,
        Paolo Abeni <pabeni@redhat.com>, Jiri Pirko <jiri@resnulli.us>,
        Ivan Vecera <ivecera@redhat.com>,
        Roopa Prabhu <roopa@nvidia.com>,
        Nikolay Aleksandrov <razor@blackwall.org>,
        Shuah Khan <shuah@kernel.org>,
        Daniel Borkmann <daniel@iogearbox.net>,
        Hans Schultz <schultz.hans+netdev@gmail.com>,
        linux-kernel@vger.kernel.org, bridge@lists.linux-foundation.org,
        linux-kselftest@vger.kernel.org
Subject: Re: [PATCH net-next v1 1/1] net: bridge: ensure that link-local
 traffic cannot unlock a locked port
Message-ID: <Yr8oPba83rpJE3GV@shredder>
References: <20220630111634.610320-1-hans@kapio-technology.com>
 <Yr2LFI1dx6Oc7QBo@shredder>
 <CAKUejP6LTFuw7d_1C18VvxXDuYaboD-PvSkk_ANSFjjfhyDGkg@mail.gmail.com>
 <Yr778K/7L7Wqwws2@shredder>
 <CAKUejP5w0Dn8y9gyDryNYy7LOUytqZsG+qqqC8JhRcvyC13=hQ@mail.gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAKUejP5w0Dn8y9gyDryNYy7LOUytqZsG+qqqC8JhRcvyC13=hQ@mail.gmail.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?KEETqChD9kLiaO0Ir4QSHO/aWBf6Qagw8mhbMuJHlSxanbZ2bS1SD+m8Q1Gv?=
 =?us-ascii?Q?AvPYZ1a8pyO0QLwh4EAPilKjL6FIZ83+ncO3nrU8WDsqitylfUO7RtUmURFC?=
 =?us-ascii?Q?MMWy+WLMpd4m0zN+7SAzDsX7pdkSPLvOn0dm+J4CSUxifAG64wrZ2drWqNky?=
 =?us-ascii?Q?1sStBhQDnRi/9QGDvr0w83AceIBk27RpRf4ViK1bvfDn0OLet2IzbKUg6COa?=
 =?us-ascii?Q?d09HiQEIGeIkjcGuvlEIzw8QcgvuiEomIGABfbUoCxfFVyJG9BKBbET/Q6Q2?=
 =?us-ascii?Q?1gitwqtFWVUMcgovpsbbXryokRs5oxd2oTjbaAq8QNBLzIV5jaDYp7bTAxqj?=
 =?us-ascii?Q?3apgxsPwYWXU76AeuXkc6/lYbrhn62GuKgpjhfkYBRlbWGZ0PHmXW0WvXyZ4?=
 =?us-ascii?Q?7hQ9xUKhgEytAmPY4m+K+Z0e3Qy2S+W7UvQ8qwJZspoR60ewO5RKBmlzfJXv?=
 =?us-ascii?Q?6qhp8Udgt0Vh3OFDF8Uk5RDQJVPoR5cowGPOAg/Qb8BdUiiY9mex8K/8MdDn?=
 =?us-ascii?Q?I1i3g9FFwWRHCxEdfmyz16460LdY596scSTPTFtAIqWmrz/tAMCg9dpQLf2D?=
 =?us-ascii?Q?UVJOtnzV5e5ugm+7V03HuEWihi5pRDZoTAmy2f8YcxzUqD7656xZpphADhKO?=
 =?us-ascii?Q?6FMyiesY0T1tsJPzSmkF5ndxaGdc+biRfi21F5F8nRw3N21OS8a2ImltsEuH?=
 =?us-ascii?Q?YxWQ0Bd8UrDEXRA2fmdoJCeSur8y0bUI7oMByxZX0WkCfOc2Afk6H+MnBKUe?=
 =?us-ascii?Q?+xnGYzm4AMLJYiftmV8zuNxxDmoC+QkZnFLDjJK04eqSdxM22tCx3OjG3HIE?=
 =?us-ascii?Q?vvloWk4lf8ACm68N34c3Blyl6Nkcv/tZgpjDdchCu6GlNoLiCG65GvpQa1ia?=
 =?us-ascii?Q?s0I6OAyaiD2GeD+m+CPcEPtoenOhPHz0ceszr2k9c6y8MJGUKV/g6g84zAgt?=
 =?us-ascii?Q?XaV/M6NR3BG55/6JIJrBh2XcyY+xYc2uSCwmrEzscIWuT0KC6CwvVWndTM1y?=
 =?us-ascii?Q?tre9krqSXQdvocRBOrbw1HwVLwpqMP2+OHjjfdvDPm83GyOawVI8DH/8KvXb?=
 =?us-ascii?Q?PgM0K0fE1Te92U7v7ig0goNk9resdRdIpVX7llp0D0WdIrXDbzg3rvZ90Za/?=
 =?us-ascii?Q?v6ZBfxjHnJB8bTbic610cggjakx4r55AgdVa6Q/HrNywVTUI6Uy5z/Js2C8G?=
 =?us-ascii?Q?MsHVdTCbaG6TbjYtPXvwNsPmFKQ64xum/yKxUfsMMwyWEBWFPcdXN9NYgiBu?=
 =?us-ascii?Q?FCnT4CAHtT8g093nr7ZOu3w4Pn+OjvO8Yds4zwY2atNGivdkbUyjlucSRkhA?=
 =?us-ascii?Q?3Wu4mLHhVGDTYEMl7Ciwu7IReD8V5p1NikT9C+TOQND+ashqHzuPb3IWqKMR?=
 =?us-ascii?Q?kdOaLBKMtPd8LZh8O9eGVK4biHPjJBe/k0U+V/LccPOgqBlIqh+kA6GL6WFS?=
 =?us-ascii?Q?Y09WOfYa/Qjvdd6nNh+Z5I0N8i5ecr3oSeJHgvZMuC1Q1weFMd/9wOainy+V?=
 =?us-ascii?Q?MIi+YCvx9Eul89guOhQEaC+wBeqoHQstKtesh1CwH52s8JbftYnVDFhCF5/g?=
 =?us-ascii?Q?9qWZ0apoAFvH07Y1htyHQloPb2QASklQHJm5uHKy?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7f10eb30-b7f4-4bb1-5ade-08da5b8340fa
X-MS-Exchange-CrossTenant-AuthSource: CY5PR12MB6179.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Jul 2022 17:00:51.6275
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 9goAaIZEA2EmTm5kHX3gsk+CT6kkflWRN3cWK1q0w0sKcMs/W9nwFfV5CkXGTIUkka5HkmB9E1KrpjwMItF7VQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1201MB0269
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_SPF_HELO,
        RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE,
        T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, Jul 01, 2022 at 06:07:10PM +0200, Hans S wrote:
> There is several issues when learning is turned off with the mv88e6xxx driver:

Please don't top-post...

> 
> Mac-Auth requires learning turned on, otherwise there will be no miss
> violation interrupts afair.
> Refreshing of ATU entries does not work with learning turn off, as the
> PAV is set to zero when learning is turned off.
> This then further eliminates the use of the HoldAt1 feature and
> age-out interrupts.
> 
> With dynamic ATU entries (an upcoming patch set), an authorized unit
> gets a dynamic ATU entry, and if it goes quiet for 5 minutes, it's
> entry will age out and thus get removed.
> That also solves the port relocation issue as if a device relocates to
> another port it will be able to get access again after 5 minutes.

You assume I'm familiar with mv88e6xxx, when in fact I'm not. Here is
what I think you are saying:

1. When a port is locked and a packet is received with a SA that is not
in the FDB, it will only generate a miss violation if learning is
enabled. In which case, you will notify the bridge driver about this
entry as externally learned and locked entry.

2. When a port is locked and a packet is received with a SA that matches
a different port, it will be dropped regardless if learning is enabled
or not.

3. From the above I conclude that the HW will not auto-populate its FDB
when a port is locked.

4. FDB entries that point to a port that does not have learning enabled
are not subject to ageing (why?).

Assuming the above is correct, in order for mv88e6xxx to work correctly,
it needs to enable learning on all locked ports, but it should happen
regardless of the bridge driver learning configuration let alone impose
any limitations on it. In fact, hostapd must disable learning for all
locked ports.