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: <f4e3ff994fe28bb2645b5fddf1850f8fcc5d1f89.camel@codeconstruct.com.au>
Date: Tue, 05 Nov 2024 22:09:15 +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,

> > > We need a hardware address to create a socket without an EID in
> > > order
> > > to know where we are sending the packets.
> > Just to clarify that: for physical (ie, null-EID) addressing, you
> > don't
> > need the hardware address, you need:
> > 
> >   1) the outgoing interface's ifindex; and
> >   2) the hardware address of the *remote* endpoint, in whatever
> >      format is appropriate for link type
> > 
> > In cases where there is no hardware addressing in the tx packet
> > (which
> > looks to apply to PCC), (2) is empty.
> > 
> > I understand that you're needing some mechanism for finding the
> > correct
> > ifindex, but I don't think using the device lladdr is the correct
> > approach.
> > 
> > We have this model already for mctp-over-serial, which is another
> > point-to-point link type. MCTP-over-serial devices have no hardware
> > address, as there is no hardware addressing in the packet format.
> > In
> > EID-less routing, it's up to the application to determine the
> > ifindex,
> > using whatever existing device-identification mechanism is
> > suitable.
> 
> I'd like to avoid having a custom mechanism to find the right 
> interface.  Agreed that this is really find 1) above: selecting the 
> outgoing interface.

OK, but from what you're adding later it sounds like you already have
part of that mechanism custom anyway: the mapping of a socket to a
channel index?

It sounds like there will always be some requirement for a
platform-specific inventory-mapping mechanism; you're going from socket
number to ifindex. It should be just as equivalent to implement that
using a sysfs attribute rather than the device lladdr, no?

> There is already an example of using the HW address in the interface: 
> the loopback has an address in it, for some reason. Probably because
> it is inherited from the Ethernet loopback.

Yes, and that the ethernet packet format does include a physical
address, hence the lladdr being present on lo.

> In our use case, we expect there to be two MCTP-PCC links available
> on a 
> 2 Socket System, one per socket.  The end user needs a way to know
> which 
> device talks to which socket.  In the case of a single socket system,
> there should only be one.
> 
> However, there is no telling how this mechanism will be used in the 
> future, and there may be MCTP-PCC enabled devices that are not bound
> to a CPU.

That's fine; I think finding an interface based on the channel numbers
seems generally applicable.

> Technically we get the signature field in the first four bytes of the
> PCC Generic Comunications channel Shared memory region:
> 
> https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/14_Platform_Communications_Channel/Platform_Comm_Channel.html#generic-communications-channel-shared-memory-region
> 
> "The PCC signature. The signature of a subspace is computed by a 
> bitwise-or of the value 0x50434300 with the subspace ID. For example,
> subspace 3 has the signature 0x50434303."

ok! so there is some form of addressing on the packet. Can we use this
subspace ID as a form of lladdr? Could this be interpreted as the
"destination" of a packet?

You do mention that it may not be suitable though:

> One possibility is to do another revision that uses  the SIGNATURE as
> the HW address, with an understanding that if the signature changes, 
> there will be a corresponding change in the HW address,

Is that signature format expected to change across DSP0292 versions?

Cheers,


Jeremy