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: <ZJa4YPtXaLOJigVM@nanopsycho>
Date: Sat, 24 Jun 2023 11:33:20 +0200
From: Jiri Pirko <jiri@...nulli.us>
To: Jakub Kicinski <kuba@...nel.org>
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

Fri, Jun 23, 2023 at 05:21:08PM CEST, kuba@...nel.org wrote:
>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

True. But I believe we can sanitize this in devlink core, not allowing
to activate zeroed mac. Instead of radom generating of a mac on the SF
side, we random generate it on the eswitch port function side.

I think this can work.


>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

True, that is why I suggested to expose hw_addr attr on devlink port of
the SF instance, where this would be fixed no matter what the user does
on the actual netdevice.


>of the SF after all, right? Probably best to find another way...


Well, yeah. The mac/hw_addr is quite convenient. It's there and
I believe that any device could work with that. Having some kind of
"extra cookie" would require to implement that in FW, which makes things
more complicated.


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