Re: [PATCH] firmware: tegra: ivc: back off when a peer stalls the handshake

[Thierry Reding <thierry.reding@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 2570 bytes --]

On Thu, Sep 17, 2026 at 05:20:24PM -0400, 0xSmash0th via B4 Relay wrote:
> From: 0xSmash0th <0xSmash0th@gmail.com>
> 
> An untrusted peer can wedge a channel for ever: park its state word on
> SYNC and stop touching the ring.  No path in tegra_ivc_notified() can
> change the victim's rx word, so rx_state stays SYNC and the loop is
> absorbing rather than slow -- pass 7,651,085 is indistinguishable from
> pass 1.  Each pass rewrites the ACK already in tx.state, re-zeroes both
> counters, rings the doorbell and returns -EAGAIN.
> 
> The only in-tree caller, tegra186_bpmp_channel_reset(), retries on that
> with no timeout, no iteration cap and no cpu_relax(), on both the probe
> and the resume path, so the victim burns a core at roughly 1.5M
> iterations per second for as long as the peer stays quiet.
> 
> A peer is a service, not a VM: one untrusted guest can hold a channel to
> each of a rack of service partitions, and nothing here makes wedging the
> tenth harder than the first.
> 
> This is not a new class of concern for ivc.c.  tegra_ivc_empty() already
> carries an over-full check "to prevent denial of service attacks", and
> calls that condition "an invalid case caused by a potentially malicious
> peer".  That defence covers the counters; the handshake has none.
> 
> Apply geometric backoff to calls that make no progress, modelled on
> xen_irq_lateeoi_locked(): a saturating count, a doubling delay, a hard
> cap, and a reset the moment the peer moves.  Progress is detected by
> reading tx.state back rather than by tracking which branch ran, so the
> states from which no branch can escape are covered too.  The wait is a
> bounded busy-wait by default because tegra_bpmp_transfer_atomic() reaches
> this with interrupts disabled, and it uses local_clock() because the
> resume path can run with timekeeping suspended.
> 
> This is a floor, not a fix.  The return value is unchanged, the caller
> still retries for ever and probe or resume still never completes -- the
> spin just stops costing what other channels have to share.  Bounding the
> loop belongs in the caller.
> 
> Assisted-by: LLM

I'm not going to bother even reading all of this. There is no such thing
as a hostile IVC peer. The one peer that currently uses this IVC in the
Linux kernel is the BPMP and if that is somehow compromised, wedging the
channel is probably the most harmless thing it can do.

> Signed-off-by: 0xSmash0th <0xSmash0th@gmail.com>

Please use your full name when submitting patches to Linux.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]