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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200419083032.GA3479405@splinter>
Date:   Sun, 19 Apr 2020 11:30:32 +0300
From:   Ido Schimmel <idosch@...sch.org>
To:     "Allan W. Nielsen" <allan.nielsen@...rochip.com>
Cc:     Vladimir Oltean <olteanv@...il.com>, davem@...emloft.net,
        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,
        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, kuba@...nel.org
Subject: Re: [PATCH net-next] net: mscc: ocelot: deal with problematic
 MAC_ETYPE VCAP IS2 rules

On Sun, Apr 19, 2020 at 09:33:07AM +0200, Allan W. Nielsen wrote:
> Hi,
> 
> Sorry I did not manage to provide feedback before it was merged (I will
> need to consult some of my colleagues Monday before I can provide the
> foll feedback).
> 
> There are many good things in this patch, but it is not only good.
> 
> The problem is that these TCAMs/VCAPs are insanely complicated and it is
> really hard to make them fit nicely into the existing tc frame-work
> (being hard does not mean that we should not try).
> 
> In this patch, you try to automatic figure out who the user want the
> TCAM to be configured. It works for 1 use-case but it breaks others.
> 
> Before this patch you could do a:
>     tc filter add dev swp0 ingress protocol ipv4 \
>             flower skip_sw src_ip 10.0.0.1 action drop
>     tc filter add dev swp0 ingress \
>             flower skip_sw src_mac 96:18:82:00:04:01 action drop
> 
> But the second rule would not apply to the ICMP over IPv4 over Ethernet
> packet, it would however apply to non-IP packets.
> 
> With this patch it not possible. Your use-case is more common, but the
> other one is not unrealistic.
> 
> My concern with this, is that I do not think it is possible to automatic
> detect how these TCAMs needs to be configured by only looking at the
> rules installed by the user. Trying to do this automatic, also makes the
> TCAM logic even harder to understand for the user.
> 
> I would prefer that we by default uses some conservative default
> settings which are easy to understand, and then expose some expert
> settings in the sysfs, which can be used to achieve different
> behavioral.
> 
> Maybe forcing MAC_ETYPE matches is the most conservative and easiest to
> understand default.
> 
> But I do seem to recall that there is a way to allow matching on both
> SMAC and SIP (your original motivation). This may be a better default
> (despite that it consumes more TCAM resources). I will follow up and
> check if this is possible.
> 
> Vladimir (and anyone else whom interested): would you be interested in
> spending some time discussion the more high-level architectures and
> use-cases on how to best integrate this TCAM architecture into the Linux
> kernel. Not sure on the outlook for the various conferences, but we
> could arrange some online session to discuss this.

Not sure I completely understand the difficulties you are facing, but it
sounds similar to a problem we had in mlxsw. You might want to look into
"chain templates" [1] in order to restrict the keys that can be used
simultaneously.

I don't mind participating in an online discussion if you think it can
help.

[1] https://github.com/Mellanox/mlxsw/wiki/ACLs#chain-templates