netdev - Re: [PATCH net 1/2] net: mscc: ocelot: fix VCAP filters not matching on MAC with "protocol 802.1Q"

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: <Y+DpAXdFCj+laoRF@corigine.com>
Date:   Mon, 6 Feb 2023 12:48:17 +0100
From:   Simon Horman <simon.horman@...igine.com>
To:     Vladimir Oltean <vladimir.oltean@....com>
Cc:     netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Claudiu Manoil <claudiu.manoil@....com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        UNGLinuxDriver@...rochip.com, linux-kernel@...r.kernel.org,
        Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        Richie Pearn <richard.pearn@....com>,
        Xiaoliang Yang <xiaoliang.yang_1@....com>
Subject: Re: [PATCH net 1/2] net: mscc: ocelot: fix VCAP filters not matching
 on MAC with "protocol 802.1Q"

On Sun, Feb 05, 2023 at 09:24:08PM +0200, Vladimir Oltean wrote:
> Alternative short title: don't instruct the hardware to match on
> EtherType with "protocol 802.1Q" flower filters. It doesn't work for the
> reasons detailed below.
> 
> With a command such as the following:
> 
> tc filter add dev $swp1 ingress chain $(IS1 2) pref 3 \
> 	protocol 802.1Q flower skip_sw vlan_id 200 src_mac $h1_mac \
> 	action vlan modify id 300 \
> 	action goto chain $(IS2 0 0)
> 
> the created filter is set by ocelot_flower_parse_key() to be of type
> OCELOT_VCAP_KEY_ETYPE, and etype is set to {value=0x8100, mask=0xffff}.
> This gets propagated all the way to is1_entry_set() which commits it to
> hardware (the VCAP_IS1_HK_ETYPE field of the key). Compare this to the
> case where src_mac isn't specified - the key type is OCELOT_VCAP_KEY_ANY,
> and is1_entry_set() doesn't populate VCAP_IS1_HK_ETYPE.
> 
> The problem is that for VLAN-tagged frames, the hardware interprets the
> ETYPE field as holding the encapsulated VLAN protocol. So the above
> filter will only match those packets which have an encapsulated protocol
> of 0x8100, rather than all packets with VLAN ID 200 and the given src_mac.
> 
> The reason why this is allowed to occur is because, although we have a
> block of code in ocelot_flower_parse_key() which sets "match_protocol"
> to false when VLAN keys are present, that code executes too late.
> There is another block of code, which executes for Ethernet addresses,
> and has a "goto finished_key_parsing" and skips the VLAN header parsing.
> By skipping it, "match_protocol" remains with the value it was
> initialized with, i.e. "true", and "proto" is set to f->common.protocol,
> or 0x8100.
> 
> The concept of ignoring some keys rather than erroring out when they are
> present but can't be offloaded is dubious in itself, but is present
> since the initial commit fe3490e6107e ("net: mscc: ocelot: Hardware
> ofload for tc flower filter"), and it's outside of the scope of this
> patch to change that.
> 
> The problem was introduced when the driver started to interpret the
> flower filter's protocol, and populate the VCAP filter's ETYPE field
> based on it.
> 
> To fix this, it is sufficient to move the code that parses the VLAN keys
> earlier than the "goto finished_key_parsing" instruction. This will
> ensure that if we have a flower filter with both VLAN and Ethernet
> address keys, it won't match on ETYPE 0x8100, because the VLAN key
> parsing sets "match_protocol = false".
> 
> Fixes: 86b956de119c ("net: mscc: ocelot: support matching on EtherType")
> Signed-off-by: Vladimir Oltean <vladimir.oltean@....com>

Reviewed-by: Simon Horman <simon.horman@...igine.com>