netdev - cls_flower vlan matching

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-next>] [day] [month] [year] [list]

Message-ID: <8735jkv2nm.fsf@nvidia.com>
Date:   Mon, 14 Mar 2022 19:26:38 +0200
From:   Vlad Buslov <vladbu@...dia.com>
To:     Jiri Pirko <jiri@...dia.com>
CC:     <netdev@...r.kernel.org>, Jamal Hadi Salim <hadi@...atatu.com>,
        "Maor Dickman" <maord@...dia.com>
Subject: cls_flower vlan matching

Hi Jiri,

I've been debugging an issue that we encounter with OvS-created rules
for single and double-VLAN packets.

Basically, for flows with single VLAN OvS creates following tc filter:

filter protocol 802.1Q pref 2 flower chain 0 
filter protocol 802.1Q pref 2 flower chain 0 handle 0x1 
  vlan_id 10                                                                                                            
  vlan_prio 0             
  vlan_ethtype ip                                                                                                       
  dst_mac e4:2c:0b:08:00:02     
  src_mac b8:ce:f6:05:e7:3a
  eth_type ipv4
  ip_flags nofrag                                                                                                       
  skip_hw                                                                                                               
  not_in_hw               
        action order 1: vlan  pop pipe                                                                                  
         index 2 ref 1 bind 1 installed 11 sec used 0 sec firstused 10 sec
        Action statistics:                     
        Sent 860 bytes 10 pkt (dropped 0, overlimits 0 requeues 0) 
        backlog 0b 0p requeues 0
        no_percpu

        action order 2: mirred (Egress Redirect to device enp8s0f0_0) stolen
        index 2 ref 1 bind 1 installed 11 sec used 0 sec firstused 10 sec
        Action statistics:
        Sent 860 bytes 10 pkt (dropped 0, overlimits 0 requeues 0) 
        backlog 0b 0p requeues 0
        cookie 16a9b603144b3e0c64a887aeb972a269
        no_percpu

Such rule also matches packets that have additional second VLAN header,
even though filter has both eth_type and vlan_ethtype set to "ipv4".
Looking at the code this seems to be mostly an artifact of the way
flower uses flow dissector. First, even though looking at the uAPI
eth_type and vlan_ethtype appear like a distinct fields, in flower they
are all mapped to the same key->basic.n_proto. Second, flow dissector
skips following VLAN header as no keys for FLOW_DISSECTOR_KEY_CVLAN are
set and eventually assigns the value of n_proto to last parsed header.
With these, such filters ignore any headers present between first VLAN
header and first "non magic" header (ipv4 in this case) that doesn't
result FLOW_DISSECT_RET_PROTO_AGAIN.

Is described behavior intentional? Any way to enforce matching for
header following the VLAN header?

Regards,
Vlad