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: <cc41ccf443b1f2c7a4cb5e247dabfa53a6674226.camel@microchip.com>
Date:   Thu, 22 Dec 2022 16:02:47 +0100
From:   Steen Hegelund <steen.hegelund@...rochip.com>
To:     Paolo Abeni <pabeni@...hat.com>,
        "David S . Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>
CC:     <UNGLinuxDriver@...rochip.com>,
        Randy Dunlap <rdunlap@...radead.org>,
        Casper Andersson <casper.casan@...il.com>,
        Russell King <rmk+kernel@...linux.org.uk>,
        Wan Jiabing <wanjiabing@...o.com>,
        "Nathan Huckleberry" <nhuck@...gle.com>,
        <linux-kernel@...r.kernel.org>, <netdev@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        "Daniel Machon" <daniel.machon@...rochip.com>,
        Horatiu Vultur <horatiu.vultur@...rochip.com>,
        Lars Povlsen <lars.povlsen@...rochip.com>,
        Dan Carpenter <error27@...il.com>
Subject: Re: [PATCH net 0/8] Add support for two classes of VCAP rules

Hi Paolo,

On Thu, 2022-12-22 at 15:22 +0100, Paolo Abeni wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
> 
> Hello,
> On Wed, 2022-12-21 at 14:25 +0100, Steen Hegelund wrote:
> > This adds support for two classes of VCAP rules:
> > 
> > - Permanent rules (added e.g. for PTP support)
> > - TC user rules (added by the TC userspace tool)
> > 
> > For this to work the VCAP Loopups must be enabled from boot, so that the
> > "internal" clients like PTP can add rules that are always active.
> > 
> > When the TC tool add a flower filter the VCAP rule corresponding to this
> > filter will be disabled (kept in memory) until a TC matchall filter creates
> > a link from chain 0 to the chain (lookup) where the flower filter was
> > added.
> > 
> > When the flower filter is enabled it will be written to the appropriate
> > VCAP lookup and become active in HW.
> > 
> > Likewise the flower filter will be disabled if there is no link from chain
> > 0 to the chain of the filter (lookup), and when that happens the
> > corresponding VCAP rule will be read from the VCAP instance and stored in
> > memory until it is deleted or enabled again.
> 
> Despite the 'net' target, this looks really like net-next material as
> most patches look like large refactor. I see there are a bunch of fixes
> in patches 3-8, but quite frankly it's not obvious at all what the
> refactors/new features described into the commit messages themself
> really fix.

Yes the patches 3-8 is the response to Michael Walles observations on LAN966x
and Jakubs Kicinski comment (see link), but the description in the commits may
not be that clear, in the sense that they do not state one-to-one what the
mitigation is.

See https://lore.kernel.org/netdev/20221209150332.79a921fd@kernel.org/

So essentially this makes it possible to have rules that are always in the VCAP
HW (to make the PTP feature work), even before the TC chains have been
established (which was the problem that Michael encountered).

I still think this a net submission, since it fixes the problem that was
observed in the previous netnext window.

But I will rephrase the reasoning in a V2 to hopefully make that more
understandable.

If you still think it is better to post this in the upcoming net-next window, I
am also OK with that.

> 
> I suggest to move this series to net-next (and thus repost after Jan
> 2), unless you come-up with some good reasons to keep it in net.
> 
> Thanks,
> 
> Paolo
> 

BR
Steen

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ