linux-hardening - Re: [PATCH RFC 4/7] i3c: add driver for Renesas I3C IP

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: <aIH1zUb8tyIlyC3S@shikoro>
Date: Thu, 24 Jul 2025 10:58:53 +0200
From: Wolfram Sang <wsa+renesas@...g-engineering.com>
To: Frank Li <Frank.li@....com>
Cc: linux-renesas-soc@...r.kernel.org,
	Tommaso Merciai <tommaso.merciai.xr@...renesas.com>,
	Alexandre Belloni <alexandre.belloni@...tlin.com>,
	Kees Cook <kees@...nel.org>,
	"Gustavo A. R. Silva" <gustavoars@...nel.org>,
	Philipp Zabel <p.zabel@...gutronix.de>,
	Geert Uytterhoeven <geert+renesas@...der.be>,
	Magnus Damm <magnus.damm@...il.com>, linux-i3c@...ts.infradead.org,
	linux-hardening@...r.kernel.org
Subject: Re: [PATCH RFC 4/7] i3c: add driver for Renesas I3C IP

> > +		renesas_i3c_enqueue_xfer(i3c, xfer);
> > +		if (!wait_for_completion_timeout(&xfer->comp, XFER_TIMEOUT))
> > +			renesas_i3c_dequeue_xfer(i3c, xfer);
> 
> This may common problem, I3C spec have 100us timeout, target side may
> timeout when driver wait for irq. So target side treat "repeat start" as
> "start" and issue address arbitration.

Looking more at this issue, I think these are two separate problems.
Chapter 5.1.2.5 mandates that the controller shall not hold SCL low for
more than 100us in most situations and by no means longer than 15ms in
any situation.

Depending on the controller, this may be need to be handled in software.
Or it may be handled in hardware which could raise an exception and
release SCL on its own if the timing was violated.

The above completion is for the *whole transfer*, though, including the
target response time. Like I2C, it is not specified for I3C. At least, I
couldn't find it and I recall no one at the I3C plugfest could point me
to one as well.

So, this completion timeout is more than just 5.1.2.5. It might make
sense to investigate a more reasonable value. But I don't think this
should be imposed on someone submitting a new driver. It is a dedicated
task. And I am not even sure the result will be a subsystem-wide static
value. It might be a calculated value. Maybe even a driver-specific
calculated value.

So, I think the best we can do until we have this investigation is to
keep drivers consistent with the historically grown value.

Or?