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: <20220111115704.4312d280@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>
Date:   Tue, 11 Jan 2022 11:57:04 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Parav Pandit <parav@...dia.com>
Cc:     Sunil Sudhakar Rani <sunrani@...dia.com>,
        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

On Tue, 11 Jan 2022 19:39:37 +0000 Parav Pandit wrote:
> > From: Jakub Kicinski <kuba@...nel.org>
> > Sent: Wednesday, January 12, 2022 12:54 AM
> > 
> > On Tue, 11 Jan 2022 18:26:16 +0000 Parav Pandit wrote:  
> > > It isn't trusted feature. The scope in few weeks got expanded from
> > > trusted to more granular at controlling capabilities. One that came up
> > > was ipsec or other offloads that consumes more device resources.  
> > 
> > That's what I thought. Resource control is different than privileges, and
> > requires a different API.
> >  
> It's the capability that is turned on/off.
> A device is composed based on what is needed. ipsec offload is not always needed.
> Its counter intuitive to expose some low level hardware resource to disable ipsec indirectly.
> So it is better to do as capability/param rather than some resource.
> It is capability is more than just resource.

Wouldn't there be some limitation on the number of SAs or max
throughput or such to limit on VF hogging the entire crypto path?

I was expecting such a knob, and then turning it to 0 would effectively
remove the capability (FW can completely hide it or driver ignore it).



> > > A prometheous kind of monitoring software wants to monitor the
> > > physical port counters, running in a container. Such container doesn't
> > > have direct access to the PF or physical representor. Just for sake of
> > > monitoring counters, user doesn't want to run the monitoring container
> > > in root net ns.  
> > 
> > Containerizing monitors seems very counter-intuitive to me.
> >  
> May be. But it is in use at [1] for a long time now.
> 
> [1] docker run -p 9090:9090 prom/prometheus

How is it "in use" if we haven't merged the patch to enable it? :)
What does it monitor? PHYs port does not include east-west traffic,
exposing just the PHYs stats seems like a half measure.

> > > For sure we prefer the bona fide Linux uAPI for standard features.
> > > But internal knobs of how to do steering etc, is something not generic
> > > enough. May be only those quirks live in the port function params and
> > > rest in standard uAPIs?  
> > 
> > Something talks to that steering API, and it's not netdev. So please don't push
> > problems which are not ours onto us.  
> Not sure I follow you.
> Netdev of a mlx5 function talks to the driver internal steering API
> in addition to other drivers operating this mlx5 function.

But there is no such thing as "steering API" in netdev. We can expose
the functionality we do have, if say PTP requires some steering then
enabling PTP implies the required steering is enabled. "steering API"
as an entity is meaningless to a netdev user.