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: <3e68ad61-8b21-4d15-bc4c-412dd2c7b53d@amperemail.onmicrosoft.com>
Date: Thu, 31 Oct 2024 11:50:49 -0400
From: Adam Young <admiyo@...eremail.onmicrosoft.com>
To: Jeremy Kerr <jk@...econstruct.com.au>, 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

We need a hardware address to create a socket without an EID in order to 
know where we are sending the packets.

The Hardware addressing is needed to be able to use the device in 
point-to-point mode.  It is possible to have multiple devices at the 
hardware level, and also to not use EID based routing.  Thus, the kernel 
needs to expose which device is which.  The Essential piece of 
information is the outbox, which identifies which channel the  message 
will be sent on.  The inbox is in the hardware address as well as a 
confirmation of on which channel the messages are expected to return. In 
the future, it is possible to reuse channels and IRQs in constrained 
situations, and the driver would then be able to deduce from the packet 
which remote device sent it.

Probably not correct to say the  there is no hardware addressing on the 
packet.  Instead, there is a portion of it on outgoing packets, and a 
different portion on incoming packets.

The hardware address format is in an upcoming version of the spec not 
yet published.

The namespace is for future expansion.  I expect this to always be 0.

I'll fix the other review corrections shortly.

On 10/30/24 21:28, Jeremy Kerr wrote:
> I recall querying this in v1, not sure if there was a response, but:
>
> Given there is no hardware addressing in the packet format, what is the
> meaning of the physical address on the interface? It's a little strange
> to define a hardware address here that isn't used for actual addressing.
>
> For point-to-point links like this (and the serial transport), it's fine
> to have no hw address on the device.
>
> If this is purely local-machine-specific instance data, I suspect that
> this belongs elsewhere. A read-only sysfs attribute could work?