netdev - Re: [patch net-next 0/4] net/mlx5: expose peer SF devlink instance

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: Fri, 18 Aug 2023 14:20:07 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Jiri Pirko <jiri@...nulli.us>
Cc: netdev@...r.kernel.org, pabeni@...hat.com, davem@...emloft.net,
 edumazet@...gle.com, moshe@...dia.com, saeedm@...dia.com, shayd@...dia.com,
 leon@...nel.org
Subject: Re: [patch net-next 0/4] net/mlx5: expose peer SF devlink instance

On Fri, 18 Aug 2023 09:30:17 +0200 Jiri Pirko wrote:
> >The devlink instance of the SF stays in the same network namespace 
> >as the PF?  
> 
> SF devlink instance is created in init_ns and can move to another one.
> So no.
> 
> I was thinking about this, as with the devlink handles we are kind of in
> between sysfs and network. We have concept of network namespace in
> devlink, but mainly because of the related netdevices.
> 
> There is no possibility of collision of devlink handles in between
> separate namespaces, the handle is ns-unaware. Therefore the linkage to
> instance in different ns is okay, I believe. Even more, It is handy as
> the user knows that there exists such linkage.
> 
> What do you think?

The way I was thinking about it is that the placement of the dl
instance should correspond to the entity which will be configuring it.

Assume a typical container setup where app has net admin in its
netns and there is an orchestration daemon with root in init_net 
which sets the containers up.

Will we ever want the app inside the netns to configure the interface
via the dl instance? Given that the SF is like giving the container
full access to the HW it seems to me that we should also delegate 
the devlink control to the app, i.e. move it to the netns?

Same thing for devlink instances of VFs.

The orchestration daemon has access to the "PF" / main dl instance of
the device, and to the ports / port fns so it has other ways to control
the HW. While the app would otherwise have no devlink access.

So my intuition is that the devlink instance should follow the SF
netdev into a namespace.

And then the next question is - once the devlink instances are in
different namespaces - do we still show the "nested_devlink" attribute?
Probably yes but we need to add netns id / link as well?