netdev - Re: [PATCH net-next] net: mscc: ocelot: deal with problematic MAC

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: <20200418.155421.1807745357594780485.davem@davemloft.net>
Date:   Sat, 18 Apr 2020 15:54:21 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     olteanv@...il.com
Cc:     horatiu.vultur@...rochip.com, alexandre.belloni@...tlin.com,
        antoine.tenart@...tlin.com, andrew@...n.ch, f.fainelli@...il.com,
        vivien.didelot@...il.com, joergen.andreasen@...rochip.com,
        allan.nielsen@...rochip.com, claudiu.manoil@....com,
        netdev@...r.kernel.org, UNGLinuxDriver@...rochip.com,
        alexandru.marginean@....com, xiaoliang.yang_1@....com,
        yangbo.lu@....com, po.liu@....com, jiri@...lanox.com,
        idosch@...sch.org, kuba@...nel.org
Subject: Re: [PATCH net-next] net: mscc: ocelot: deal with problematic
 MAC_ETYPE VCAP IS2 rules

From: Vladimir Oltean <olteanv@...il.com>
Date: Fri, 17 Apr 2020 22:03:08 +0300

> From: Vladimir Oltean <vladimir.oltean@....com>
> 
> By default, the VCAP IS2 will produce a single match for each frame, on
> the most specific classification.
> 
> Example: a ping packet (ICMP over IPv4 over Ethernet) sent from an IP
> address of 10.0.0.1 and a MAC address of 96:18:82:00:04:01 will match
> this rule:
> 
> tc filter add dev swp0 ingress protocol ipv4 \
> 	flower skip_sw src_ip 10.0.0.1 action drop
> 
> but not this one:
> 
> tc filter add dev swp0 ingress \
> 	flower skip_sw src_mac 96:18:82:00:04:01 action drop
> 
> Currently the driver does not really warn the user in any way about
> this, and the behavior is rather strange anyway.
> 
> The current patch is a workaround to force matches on MAC_ETYPE keys
> (DMAC and SMAC) for all packets irrespective of higher layer protocol.
> The setting is made at the port level.
> 
> Of course this breaks all other non-src_mac and non-dst_mac matches, so
> rule exclusivity checks have been added to the driver, in order to never
> have rules of both types on any ingress port.
> 
> The bits that discard higher-level protocol information are set only
> once a MAC_ETYPE rule is added to a filter block, and only for the ports
> that are bound to that filter block. Then all further non-MAC_ETYPE
> rules added to that filter block should be denied by the ports bound to
> it.
> 
> Signed-off-by: Vladimir Oltean <vladimir.oltean@....com>

Applied.