linux-kernel - Re: [PATCH net-next] net: mctp: Expose transport binding identifier via IFLA attribute

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: <84fa07f08bce8af2018e4f81949d227c9b97fe0c.camel@codeconstruct.com.au>
Date: Fri, 08 Nov 2024 16:10:49 +0800
From: Jeremy Kerr <jk@...econstruct.com.au>
To: Jakub Kicinski <kuba@...nel.org>, Khang Nguyen
	 <khangng@...amperecomputing.com>
Cc: Matt Johnston <matt@...econstruct.com.au>, Andrew Lunn
 <andrew+netdev@...n.ch>, "David S. Miller" <davem@...emloft.net>, Eric
 Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, Simon
 Horman <horms@...nel.org>, netdev@...r.kernel.org,
 linux-kernel@...r.kernel.org, 
 ampere-linux-kernel@...ts.amperecomputing.com, Phong Vo
 <phong@...amperecomputing.com>, Thang Nguyen
 <thang@...amperecomputing.com>,  Khanh Pham <khpham@...erecomputing.com>,
 Phong Vo <pvo@...erecomputing.com>, Quan Nguyen
 <quan@...amperecomputing.com>, Chanh Nguyen <chanh@...amperecomputing.com>,
  Thu Nguyen <thu@...amperecomputing.com>, Hieu Le
 <hieul@...erecomputing.com>, openbmc@...ts.ozlabs.org, 
 patches@...erecomputing.com
Subject: Re: [PATCH net-next] net: mctp: Expose transport binding identifier
 via IFLA attribute

Hi Jakub,

> > However, we currently have no means to get this information from
> > MCTP links.
> 
> I'm not opposed to the netlink attribute, but to be clear this info 
> is indirectly available in sysfs, right? We link the netdev to 
> the parent device so the type of /sys/class/net/$your_ifc/device
> should reveal what the transport is?

It's likely derivable from the parent device, but requires some
heuristics in userspace to map this to a transport type.

Having a well-defined place to provide the DMTF-specified transport
identifier makes this a little more straightforward to determine which
spec we're dealing with, for any transport-specific behaviour. For
example, some bus types require endpoints to announce their presence,
others do not.

Cheers,


Jeremy