netdev - RE: MCTP - Bus lock between send and receive

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] [day] [month] [year] [list]

Message-ID: 
 <SJ0PR19MB4415E78B5C71405579E78F9987512@SJ0PR19MB4415.namprd19.prod.outlook.com>
Date: Mon, 19 Feb 2024 14:16:42 +0000
From: "Ramaiah, DharmaBhushan" <Dharma.Ramaiah@...l.com>
To: Jeremy Kerr <jk@...econstruct.com.au>,
        "netdev@...r.kernel.org"
	<netdev@...r.kernel.org>,
        "matt@...econstruct.com.au"
	<matt@...econstruct.com.au>
Subject: RE: MCTP - Bus lock between send and receive

Hello Jeremy,

Thanks for the reply.

Regards,
Dharma


Internal Use - Confidential
-----Original Message-----
From: Jeremy Kerr <jk@...econstruct.com.au>
Sent: 17 February 2024 05:42
To: Ramaiah, DharmaBhushan <Dharma_Ramaiah@...l.com>; netdev@...r.kernel.org; matt@...econstruct.com.au
Subject: Re: MCTP - Bus lock between send and receive


[EXTERNAL EMAIL]

Hi Dharma,

> Linux implementation of the MCTP is via sockets and is realized using
> the “sendto” and “recvfrom”. Requestor intending to send a request
> uses “sendto” and the response is obtained using “recvfrom”. From the
> basic code walkthrough, it appears that the i2c bus is not locked
> between the “sendto” and “recvfrom” i.e., bus is not locked till the
> response is received.

We do take the i2c bus lock over the duration of the MCTP request/response (or timeout if there is no response). Most of the logic is here:

  https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/mctp/mctp-i2c.c*n483__;Iw!!LpKI!j8A9vrL45XMbUzdOWjkdRqBoFoPVYG3HQqorpuNpk8Y2xXZfDufp8rrzJeQfQ3pzWfoY2si1o7ltjgI6yc8$ [git[.]kernel[.]org]

>  This presents following problems.
>
>    1. If multiple applications are communicating to the same device,
> device may end up receiving back-to-back requests before sending the
> response for the first request. Few of the devices may not support
> multiple outstanding commands and few of the cases depending on the
> protocol it might throw device into unknown state.

The bus lock does not exclude this. MCTP, as well as some upper-layer protocols, have specific provisions for multiple messages in flight, and we assume that the devices will generally behave correctly here. If not, we can generally quirk this in an upper layer application.

If there are misbehaving devices that require special handling across protocols, we could look at implementing specific behaviours for those, but would need details first...

>    1. Consider a case of mux on the I2C bus and there are multiple
> MCTP devices connected on each mux segment. Applications intending to
> communicate to a device on a different mux segment at the same time
> might mux out each other causing the response to be dropped.

Yes, this is the primary use-case for the bus locking.

> Is my understanding correct and is this a known limitation of MCTP on
> Linux?

No, this is not correct - we do have bus locking implemented.

Cheers,


Jeremy