netdev - Re: [PATCH v6 2/2] mctp pcc: Implement MCTP over PCC Transport

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: <f8454df795572983fb83c4ea78b64006a05ef79b.camel@codeconstruct.com.au>
Date: Wed, 06 Nov 2024 18:47:47 +0800
From: Jeremy Kerr <jk@...econstruct.com.au>
To: Adam Young <admiyo@...eremail.onmicrosoft.com>, 
 admiyo@...amperecomputing.com, Matt Johnston <matt@...econstruct.com.au>, 
 "David S. Miller" <davem@...emloft.net>, Eric Dumazet
 <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni
 <pabeni@...hat.com>
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org, Sudeep Holla
	 <sudeep.holla@....com>, Jonathan Cameron <Jonathan.Cameron@...wei.com>, 
	Huisong Li <lihuisong@...wei.com>
Subject: Re: [PATCH v6 2/2] mctp pcc: Implement MCTP over PCC Transport

Hi Adam,

> Adding the inbox id ( to the HW address does not harm anything, and
> it makes things much more explicit.

My issue is that these inbox/outbox/subspace IDs do not align with what
the device lladdr represents.

>From what you have said so far, and from what I can glean from the
spec, what you have here is device *instance* information, not device
*address* information.

For an address, I would expect that to represent the address of the
interface on whatever downstream bus protocol is being used. Because
the packet formats do not define any addressing mechanism (ie, packets
are point-to-point), there is no link-layer addressing performed by the
device.

You mentioned that there may, in future, be shared resources between
multiple PCC interfaces (eg, a shared interrupt), but that doesn't
change the point-to-point nature of the packet format, and hence the
lack of bus/device addresses.

This is under my assumption that a PCC interface will always represent
a pair of in/out channels, to a single remote endpoint. If that won't
be the case in future, then two things will need to happen:

 - we will need a change in the packet format to specify the
   source/destination addresses for a tx/rx-ed packet; and

 - we will *then* need to store a local address on the lladdr of the
   device, and implement neighbour-table lookups to query remote
   lladdrs.

is that what the upcoming changes are intended to do? A change to the
packet format seems like a fundamental rework to the design here.

> It seems like removing either the inbox or the outbox id from the HW 
> address is hiding information that should be exposed.

We can definitely expose all of the necessary instance data, but it
sounds like the lladdr is not the correct facility for this.

We already have examples of this instance information, like the
persistent onboard-naming scheme of ethernet devices. These are
separate from lladdr of those devices.

Cheers,

Jeremy