linux-kernel - Re: [V2 net-next] net: mvpp2: Add reserved port private flag configuration

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:   Thu, 11 Mar 2021 12:33:13 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     <stefanc@...vell.com>
Cc:     <netdev@...r.kernel.org>, <thomas.petazzoni@...tlin.com>,
        <davem@...emloft.net>, <nadavh@...vell.com>,
        <ymarkman@...vell.com>, <linux-kernel@...r.kernel.org>,
        <linux@...linux.org.uk>, <mw@...ihalf.com>, <andrew@...n.ch>,
        <rmk+kernel@...linux.org.uk>, <atenart@...nel.org>,
        <rabeeh@...id-run.com>
Subject: Re: [V2 net-next] net: mvpp2: Add reserved port private flag
 configuration

On Thu, 11 Mar 2021 18:43:27 +0200 stefanc@...vell.com wrote:
> According to Armada SoC architecture and design, all the PPv2 ports
> which are populated on the same communication processor silicon die
> (CP11x) share the same Classifier and Parser engines.
> 
> Armada is an embedded platform and therefore there is a need to reserve
> some of the PPv2 ports for different use cases.
> 
> For example, a port can be reserved for a CM3 CPU running FreeRTOS for
> management purposes or by user-space data plane application.
> 
> During port reservation all common configurations are preserved and
> only RXQ, TXQ, and interrupt vectors are disabled.
> Since TXQ's are disabled, the Kernel won't transmit any packet
> from this port, and to due the closed RXQ interrupts, the Kernel won't
> receive any packet.
> The port MAC address and administrative UP/DOWN state can still
> be changed.
> The only permitted configuration in this mode is MTU change.
> The driver's .ndo_change_mtu callback has logic that switches between
> percpu_pools and shared pools buffer mode, since the buffer management
> not done by Kernel this should be permitted.

Andrew asks good questions. This looks like a strange construct.

IMO Linux should either not see the port (like it doesn't see NC-SI),
or we need representors for physical and logical ports and explicit
forwarding rules.