netdev - RE: [PATCH net-next 1/2] devlink: Add support to set port function as trusted

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: <PH0PR12MB54817CE7826A6E924AE50B9BDC519@PH0PR12MB5481.namprd12.prod.outlook.com>
Date:   Tue, 11 Jan 2022 16:57:54 +0000
From:   Parav Pandit <parav@...dia.com>
To:     Jakub Kicinski <kuba@...nel.org>,
        Sunil Sudhakar Rani <sunrani@...dia.com>
CC:     Saeed Mahameed <saeedm@...dia.com>, Jiri Pirko <jiri@...dia.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        Bodong Wang <bodong@...dia.com>
Subject: RE: [PATCH net-next 1/2] devlink: Add support to set port function as
 trusted

Hi Jakub,

> From: Jakub Kicinski <kuba@...nel.org>
> Sent: Thursday, December 16, 2021 9:58 PM
> 
> On Thu, 16 Dec 2021 16:17:29 +0000 Sunil Sudhakar Rani wrote:
> > > On Wed, 15 Dec 2021 22:15:10 +0000 Saeed Mahameed wrote:
> > > > We will have a parameter per feature we want to enable/disable
> > > > instead of a global "trust" knob.
> > >
> > > So you're just asking me if I'm okay with devlink params regardless
> > > if I'm okay with what they control? Not really, I prefer an API as created by
> this patches.
> >
> > What shortcomings do you see in the finer granular approach we want to
> > go to enable/disable On a per feature basis instead of global knob?
> 
> I was replying to Saeed so I assumed some context which you probably lack.
> Granular approach is indeed better, what I was referring to when I said "prefer
> an API as created by this patch" was having an dedicated devlink op, instead of
> the use of devlink params.
This discussed got paused in yet another year-end holidays. :)
Resuming now and refreshing everyone's cache.

We need to set/clear the capabilities of the function before deploying such function.
As you suggested we discussed the granular approach and at present we have following features to on/off.

Generic features:
1. ipsec offload
2. ptp device

Device specific:
1. sw steering
2. physical port counters query

It was implicit that a driver API callback addition for both types of features is not good.
Devlink port function params enables to achieve both generic and device specific features.
Shall we proceed with port function params? What do you think?