linux-kernel - 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: <a4cf6516df6a7db734898a45907ff6f545acfd17.camel@codeconstruct.com.au>
Date: Tue, 12 Nov 2024 09:00:34 +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,
> 
> "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."
> 
> This could be used, but the inclusion of the "PCC" is unnecessary, as
> it is on every packet.  Thus only the subspace ID is relevant. This
> is the  index of the  entry in the PCCT, and is what I have been
> calling the  outbox ID. Thus it is half of the address that I am
> proposing.

But the signature value isn't implementing any MCTP-bus addressing
functionality, right? It's a fixed value that has to be set the same
way on all transactions using that PCC channel.

Just to walk it back a bit, we have two possible interpretations here:

 1) that the channel indexes *do* form something like a physical 
    addressing mechanism; when packets are sent over a channel to a
    remote endpoint, we need to add a specific channel identifier.

 2) that the channel indices are more of an internal detail of the
    transport mechanism: they're identifying channels, not MCTP
    endpoints (kinda like setting the PCIe target address when
    transmitting a network packet, perhaps?)

If we adopt the (1) approach, we'd want a hardware address to represent
the mechanism for addressing an MCTP endpoint, not an interface
instance. That would end up with something along the lines of:

 - MCTP-over-PCC hardware addresses would be a single byte (to contain a
   channel ID)

 - the interface would have a hardware address of just the inbox ID:
   incoming packets are received via the inbox to the local interface,
   and so are "addressed" to that inbox ID

 - remote endpoints would be represented by a hardware address of just
   the outbox ID: outgoing packets are sent via the outbox to the remote
   endpoint, so are "addressed" to that outbox ID

... but that doesn't seem to be the approach you want to take here, as
it doesn't match your requirements for an interface lladdr (also,
implementing the neighbour-handling infrastructure for that would seem
to be overkill for a strictly peer-to-peer link type).

So a couple of queries to get us to a decision:

Your goal with exposing the channel numbers is more to choose the
correct *local* interface to use on a system, right? Can you elaborate
on your objections for using something like sysfs attributes for that?

Can you outline the intended usage of the spec updates that would add
the address format you mentioned? Is there a use-case we need to
consider for those?

Cheers,

Jeremy