netdev - Re: [PATCH net-next v3 1/2] net: mscc: ocelot: Add support for tcam

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]

Date:   Mon, 24 Feb 2020 13:32:13 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Horatiu Vultur <horatiu.vultur@...rochip.com>
Cc:     Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Microchip Linux Driver Support <UNGLinuxDriver@...rochip.com>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Ralf Baechle <ralf@...ux-mips.org>,
        Paul Burton <paul.burton@...s.com>,
        James Hogan <jhogan@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        linux-mips@...r.kernel.org, devicetree@...r.kernel.org,
        lkml <linux-kernel@...r.kernel.org>,
        netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next v3 1/2] net: mscc: ocelot: Add support for tcam

Hi Horatiu,

On Mon, 24 Feb 2020 at 13:03, Horatiu Vultur
<horatiu.vultur@...rochip.com> wrote:
>
> Hi Vladimir,
>
> The 02/24/2020 12:38, Vladimir Oltean wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> >
> > Hi Horatiu,
> >
> > On Fri, 31 May 2019 at 10:18, Horatiu Vultur
> > <horatiu.vultur@...rochip.com> wrote:
> > >
> > > Add ACL support using the TCAM. Using ACL it is possible to create rules
> > > in hardware to filter/redirect frames.
> > >
> > > Signed-off-by: Horatiu Vultur <horatiu.vultur@...rochip.com>
> > > ---
> > >  arch/mips/boot/dts/mscc/ocelot.dtsi      |   5 +-
> > >  drivers/net/ethernet/mscc/Makefile       |   2 +-
> > >  drivers/net/ethernet/mscc/ocelot.c       |  13 +
> > >  drivers/net/ethernet/mscc/ocelot.h       |   8 +
> > >  drivers/net/ethernet/mscc/ocelot_ace.c   | 777 +++++++++++++++++++++++++++++++
> > >  drivers/net/ethernet/mscc/ocelot_ace.h   | 227 +++++++++
> > >  drivers/net/ethernet/mscc/ocelot_board.c |   1 +
> > >  drivers/net/ethernet/mscc/ocelot_regs.c  |  11 +
> > >  drivers/net/ethernet/mscc/ocelot_s2.h    |  64 +++
> > >  drivers/net/ethernet/mscc/ocelot_vcap.h  | 403 ++++++++++++++++
> > >  10 files changed, 1508 insertions(+), 3 deletions(-)
> > >  create mode 100644 drivers/net/ethernet/mscc/ocelot_ace.c
> > >  create mode 100644 drivers/net/ethernet/mscc/ocelot_ace.h
> > >  create mode 100644 drivers/net/ethernet/mscc/ocelot_s2.h
> > >  create mode 100644 drivers/net/ethernet/mscc/ocelot_vcap.h
> > >
> >
> > I was testing this functionality and it looks like the MAC_ETYPE keys
> > (src_mac, dst_mac) only match non-IP frames.
> > Example, this rule doesn't drop ping traffic:
> >
> > tc qdisc add dev swp0 clsact
> > tc filter add dev swp0 ingress flower skip_sw dst_mac
> > 96:e1:ef:64:1b:44 action drop
> >
> > Would it be possible to do anything about that?
>
> What you could do is to configure each port in such a way, to treat IP
> frames as MAC_ETYPE frames. Have a look in ANA:PORT[0-11]:VCAP_S2_CFG.
>
> There might be a problem with this approach. If you configure the port
> in such a way, then all your rules with the keys IP6, IP4 will not be
> match on that port.
>

Thanks for the quick answer.
Doing that is indeed problematic and would not be my first choice. I
was expecting MAC_ETYPE rules to always match an Ethernet frame
regardless of higher-level protocols, and that the user would decide
the behavior via rule ordering.

> >
> > Thanks,
> > -Vladimir
>
> --
> /Horatiu

-Vladimir