netdev - Re: [net-next 14/15] net/mlx5: Light probe local SFs

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: <20230623082108.7a4973cc@kernel.org>
Date: Fri, 23 Jun 2023 08:21:08 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Jiri Pirko <jiri@...nulli.us>
Cc: Saeed Mahameed <saeed@...nel.org>, Saeed Mahameed <saeedm@...dia.com>,
 "David S. Miller" <davem@...emloft.net>, Paolo Abeni <pabeni@...hat.com>,
 Eric Dumazet <edumazet@...gle.com>, netdev@...r.kernel.org, Tariq Toukan
 <tariqt@...dia.com>, Shay Drory <shayd@...dia.com>, Moshe Shemesh
 <moshe@...dia.com>
Subject: Re: [net-next 14/15] net/mlx5: Light probe local SFs

On Fri, 23 Jun 2023 11:27:10 +0200 Jiri Pirko wrote:
> Thu, Jun 22, 2023 at 06:35:23PM CEST, kuba@...nel.org wrote:
> >SG. For the IPU case when spawning from within the IPU can we still
> >figure out what the auxdev id is going to be? If not maybe we should  
> 
> Yeah, the driver is assigning the auxdev id. I'm now trying to figure
> out how to pass that to devlink code/user nicely. The devlink instance
> for the SF does not exist yet, but we know what the handle is going to
> be. Perhaps some sort of place holder instance would do. IDK.
> 
> >add some form of UUID on both the port and the sf devlink instance?  
> 
> What about the MAC?
> 
> $ sudo devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 102
> pci/0000:08:00.0/32769: type eth netdev eth8 flavour pcisf controller 0 pfnum 0 sfnum 102 splittable false
>   function:
>     hw_addr 00:00:00:00:00:00 state inactive opstate detached
> $ sudo devlink port function set pci/0000:08:00.0/32769 hw_addr AA:22:33:44:55:66
> $ sudo devlink port function set pci/0000:08:00.0/32769 state active
> $ ip link show eth9
> 15: eth9: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
>     link/ether aa:22:33:44:55:66 brd ff:ff:ff:ff:ff:ff
> 
> There are 2 issues with this:
> 1) If the hw_addr stays zeroed for activation, random MAC is generated
> 2) On the SF side, the MAC is only seen for netdev. That is problematic
>    for SFs without netdev. However, I don't see why we cannot add
>    devlink port attr to expose hw_addr on the SF.

Yeah, the fact that mac add of zero has special meaning could be
problematic. Other vendors may get "inspired" by the legacy SR-IOV
semantics of MAC addr of zero == user can decide, or whatnot.
The value on the port is the admin-set MAC, not the current MAC
of the SF after all, right? Probably best to find another way...

> >Maybe there's already some UUID in the vfio world we can co-opt?  
> 
> Let me check that out.