linux-kernel - RE: [EXT] Re: [PATCH v1 net-next 4/6] net: mscc: ocelot: VCAP IS1 support

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: <DB8PR04MB5785BE9AC6FAC6F395C8A20DF0A50@DB8PR04MB5785.eurprd04.prod.outlook.com>
Date:   Thu, 7 May 2020 11:23:14 +0000
From:   Xiaoliang Yang <xiaoliang.yang_1@....com>
To:     "Allan W. Nielsen" <allan.nielsen@...rochip.com>,
        Vladimir Oltean <olteanv@...il.com>
CC:     Po Liu <po.liu@....com>, Claudiu Manoil <claudiu.manoil@....com>,
        Alexandru Marginean <alexandru.marginean@....com>,
        Vladimir Oltean <vladimir.oltean@....com>,
        Leo Li <leoyang.li@....com>, Mingkai Hu <mingkai.hu@....com>,
        Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        Vivien Didelot <vivien.didelot@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jiri Pirko <jiri@...nulli.us>,
        Ido Schimmel <idosch@...sch.org>,
        Jakub Kicinski <kuba@...nel.org>,
        netdev <netdev@...r.kernel.org>,
        lkml <linux-kernel@...r.kernel.org>,
        Horatiu Vultur <horatiu.vultur@...rochip.com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Joergen Andreasen <joergen.andreasen@...rochip.com>,
        Microchip Linux Driver Support <UNGLinuxDriver@...rochip.com>,
        Nikolay Aleksandrov <nikolay@...ulusnetworks.com>,
        Roopa Prabhu <roopa@...ulusnetworks.com>,
        "linux-devel@...ux.nxdi.nxp.com" <linux-devel@...ux.nxdi.nxp.com>
Subject: RE: [EXT] Re: [PATCH v1 net-next 4/6] net: mscc: ocelot: VCAP IS1
 support

Hi Allan,


> Hi Vladimir,
> 
> On 06.05.2020 13:53, Vladimir Oltean wrote:
[snip]
> >At the moment, the driver does not support more than 1 action. We might 
> >need to change that, but we can still install more filters with the 
> >same key and still be fine (see more below). When there is more than 1 
> >action, the IS1 stuff will be combined into a single rule programmed 
> >into IS1, and the IS2 stuff will be combined into a single new rule 
> >with the same keys installed into VCAP IS2. Would that not work?
> >
> >> The SW model have these two rules in the same table, and can stop 
> >> process at the first match. SW will do the action of the first frame 
> >> matching.
> >>
> >
> >Actually I think this is an incorrect assumption - software stops at 
> >the first action only if told to do so. Let me copy-paste a text from a 
> >different email thread.
> 
> I'm still not able to see how this proposal will give us the same behavioral in SW and in HW.
> 
> A simple example:
> 
> tc qdisc add dev enp0s3 ingress
> tc filter add dev enp0s3 protocol 802.1Q parent ffff: \
>      prio 10 flower vlan_id 5 action vlan modify id 10 tc filter add dev enp0s3 protocol 802.1Q parent ffff: \
>      prio 20 flower src_mac 00:00:00:00:00:08 action drop
> 
> We can then inject a frame with VID 5 and smac ::08:
> $ ef tx tap0 eth smac 00:00:00:00:00:08 ctag vid 5
> 
> We can then check the filter and see that it only hit the first rule:
> 
> $ tc -s filter show dev enp0s3 ingress
> filter protocol 802.1Q pref 10 flower chain 0 filter protocol 802.1Q pref 10 flower chain 0 handle 0x1
>    vlan_id 5
>    not_in_hw
>          action order 1: vlan  modify id 10 protocol 802.1Q priority 0 pipe
>           index 1 ref 1 bind 1 installed 19 sec used 6 sec
>          Action statistics:
>          Sent 42 bytes 1 pkt (dropped 0, overlimits 0 requeues 0)
>          backlog 0b 0p requeues 0
>
> filter protocol 802.1Q pref 20 flower chain 0 filter protocol 802.1Q pref 20 flower chain 0 handle 0x1
>   src_mac 00:00:00:00:00:08
>   not_in_hw
>         action order 1: gact action drop
>          random type none pass val 0
>          index 1 ref 1 bind 1 installed 11 sec used 11 sec
>         Action statistics:
>         Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>         backlog 0b 0p requeues 0
>
> If this was done with the proposed HW offload, then both rules would have been hit and we would have a different behavioral.
>
> This can be fixed by adding the "continue" action to the first rule:

> tc filter add dev enp0s3 protocol 802.1Q parent ffff: \
>      prio 10 flower vlan_id 5 action vlan modify id 10 continue tc filter add dev enp0s3 protocol 802.1Q parent ffff: \
>      prio 20 flower src_mac 00:00:00:00:00:08 action drop
>
> But that would again break if we add 2 rules manipulating the VLAN (as the HW does not continue with in a single TCAM).
>
> My point is: I do not think we can hide the fact that this is done in independent TCAMs in the silicon.
> 
> I think it is possible to do this with the chain feature (even though it is not a perfect match), but it would require more analysis.
> 
> /Allan

Do you mean it's better to set vlan modify filters in a different chain, and write the filter entries with a same chain in the same VCAP TCAM?
For example:
	tc filter add dev enp0s3 protocol 802.1Q chain 11 parent ffff: prio 10 flower skip_sw vlan_id 5 action vlan modify id 10
	tc filter add dev enp0s3 protocol 802.1Q chain 22 parent ffff: prio 20 flower skip_sw src_mac 00:00:00:00:00:08 action drop
for this usage, we only need to ensure a chain corresponding to a VCAP in ocelot ace driver. I'm not sure is my understanding right?

regards,
Xiaoliang