netdev - Re: [PATCH net-next v2 5/9] selftests: hsr: Add tests for more link faults with PRP

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: <aYIVCHouYi5h1dHU@thinkpad>
Date: Tue, 3 Feb 2026 16:32:24 +0100
From: Felix Maurer <fmaurer@...hat.com>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: netdev@...r.kernel.org, davem@...emloft.net, edumazet@...gle.com,
	kuba@...nel.org, pabeni@...hat.com, horms@...nel.org,
	jkarrenpalo@...il.com, tglx@...utronix.de, mingo@...nel.org,
	allison.henderson@...cle.com, petrm@...dia.com, antonio@...nvpn.net
Subject: Re: [PATCH net-next v2 5/9] selftests: hsr: Add tests for more link
 faults with PRP

On Tue, Feb 03, 2026 at 03:49:03PM +0100, Sebastian Andrzej Siewior wrote:
> On 2026-02-03 13:09:40 [+0100], Felix Maurer wrote:
> > I agree, the reboot case is safe because of the 500ms quiet period. But
> > I kinda fear a situation where a node sends a lot of packets (making
> > it's sequence number wrap within the 400ms), but only a small fraction
>
> wrap? A lot of packets means you force-recycle the oldest block. This
> doesn't have an impact on timing.
>
> > of that to us, so that we don't clear blocks because of a full buffer.
>
> Why does this make a difference? Are you describing it from PRP
> perspective? From HSR point of view, each node sees all frames. If you
> have HW support for de-duplication then you don't see duplicates.

Good point, I didn't state that explicitly. All of my reasoning was
based on a PRP perspective, where we don't necessarily see all frames.

> > That could make a block live pretty long, when we hit it multiple times,
> > which could in turn lead to valid, new frames being dropped. I'd say
>
> The block covers up to 128 frames and you have 64 blocks. This covers
> 8192 incremental seq-numbers and every block gets recycled 8 times until
> the seq-number overflow.
>
> I think you are afraid if a node sends 65536 packets in less than 400ms
> and the receiving node observes only a fraction of it (less than 8192)
> so it does not expire blocks by force. This may indeed lead to dropping
> "new" packets.
> But this should be only a PRP problem or also a HSR problem if the used
> sequence number has "random" increments.

Yes, that's about the scenario I'm considering (I very much agree it's
an edge case, though). At it's face, this is only a PRP problem.

But I think this PRP problem can extend into an HSR ring. The standard
describes how HSR rings can be coupled to a PRP network using two
RedBoxes in HSR-PRP mode. Assuming a node in the PRP network sends a
frame, if the RedBox knows the receiver is a node in the PRP network, it
will not inject the frame into the HSR ring.  Therefore, the MACs in the
PRP network could be appearing as nodes sending with random increments
in our HSR ring. Notably, we can't know if such RedBoxes exist in our
ring. Yeah, it's another condition that needs to be met, and the edge
case get's thinner.

Thanks,
   Felix