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:
 <OSQPR06MB72527A056D135FE021A885208B72A@OSQPR06MB7252.apcprd06.prod.outlook.com>
Date: Wed, 18 Jun 2025 05:02:29 +0000
From: Billy Tsai <billy_tsai@...eedtech.com>
To: Frank Li <Frank.li@....com>
CC: "jk@...econstruct.com.au" <jk@...econstruct.com.au>,
	"alexandre.belloni@...tlin.com" <alexandre.belloni@...tlin.com>,
	"aniketmaurya@...gle.com" <aniketmaurya@...gle.com>,
	"jarkko.nikula@...ux.intel.com" <jarkko.nikula@...ux.intel.com>,
	"Shyam-sundar.S-k@....com" <Shyam-sundar.S-k@....com>,
	"wsa+renesas@...g-engineering.com" <wsa+renesas@...g-engineering.com>,
	"linux-i3c@...ts.infradead.org" <linux-i3c@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, BMC-SW
	<BMC-SW@...eedtech.com>, "elbadrym@...gle.com" <elbadrym@...gle.com>,
	"romlem@...gle.com" <romlem@...gle.com>
Subject: Re: [PATCH] i3c: ast2600: Generate T-bits to terminate IBI storm

On Wed, Jun 11, 2025 at 12:02:03PM +0800, Billy Tsai wrote:
> > Under certain conditions, such as when an IBI interrupt is received and
> > SDA remains high after the address phase,

> Can you descript more clear?
> 
> Generally IBI happen at below two case
> 1. SDA pull down by target
> 2. Address arbitration happen
> 
> Then Host send out ACK,  according to your descrpition, look like host
> NACK target IBI request.

No, it means that the Host acknowledges the IBI request. If the target device
then encounters any issue—for example, if the device shuts down at that
moment—the SDA will remain high during the data transfer phase, and the Host
will miss the T-bit to terminate the transfer.

> > the I3C controller will enter
> > an infinite loop attempting to read data until a T-bit is detected.

> BCR/DCR have indicate IBI mandatory data length. You should know how many
> data need be read according to IBI won's target address. Why relay on T-bit,
> which just is used for when target have less data than what expected.

IBI relies on the T-bit to terminate the data transfer, and the BCR is only
used to indicate whether the IBI includes data or not; it does not specify the
IBI data length. The IBI data length is controlled via the SETMRL/GETMRL
commands. The specification does not state that the Host must use the IBI data
length to terminate the transfer. However, this behavior can lead to an
unrecoverable condition in our hardware. Therefore, this patch is necessary to
recover the hardware from such scenarios.


> > This commit addresses the issue by generating a fake T-bit to terminate
> > the IBI storm when the received IBI data length exceeds the maximum
> > allowable IBI payload.

> Add empty line here.

> > This issue cannot be resolved using the abort function, as it is
> > ineffective when the I3C FSM is in the Servicing IBI Transfer (0xE) or
> > Clock Extension (0x12) states.

> why ineffective?

The abort function is not effective when the I3C FSM is in either of these
two states; this is a hardware limitation.

Thanks

Billy Tsai

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ