netdev - Re: [RESEND PATCH net-next 1/4] net: hsr: generate supervision frame without HSR tag

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

Date:   Sun, 7 Feb 2021 01:43:24 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     George McCollister <george.mccollister@...il.com>
Cc:     Jakub Kicinski <kuba@...nel.org>, Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Jonathan Corbet <corbet@....net>, netdev@...r.kernel.org
Subject: Re: [RESEND PATCH net-next 1/4] net: hsr: generate supervision frame
 without HSR tag

On Tue, Feb 02, 2021 at 08:49:25AM -0600, George McCollister wrote:
> > > > Why is it such a big deal if supervision frames have HSR/PRP tag or not?
> > >
> > > Because if the switch does automatic HSR/PRP tag insertion it will end
> > > up in there twice. You simply can't send anything with an HSR/PRP tag
> > > if this is offloaded.
> >
> > When exactly will your hardware push a second HSR tag when the incoming
> > packet already contains one? Obviously for tagged packets coming from
> > the ring it should not do that. It must be treating the CPU port special
> > somehow, but I don't understand how.
>
> From the datasheet I linked before:
> "At input the HSR tag is always removed if the port is in HSR mode. At
> output a HSR tag is added if the output port is in HSR mode."
> I don't see a great description of what happens internally when it's
> forwarding from one redundant port to the other when in HSR (not PRP)
> but perhaps it strips off the tag information, saves it and reapplies
> it as it's going out? The redundant ports are in HSR mode, the CPU
> facing port is not. Anyway I can tell you from using it, it does add a
> second HSR tag if the CPU port sends a frame with one and the frames
> going between the ring redundancy ports are forwarded with their
> single tag.

So if I understand correctly, the CPU port is configured as an interlink
port, which according to the standard can operate in 3 modes:
1) HSR-SAN: the traffic on the interlink is not HSR, not PRP
2) HSR-PRP: the traffic on the interlink is PRP-tagged as “A” or “B”
3) HSR-HSR the traffic on the interlink is HSR-tagged.

What you are saying is equivalent to the CPU port being configured for a
HSR-SAN interlink. If the CPU port was configured as HSR-HSR interlink,
this change would have not been necessary.

However 6.7 Allowed Port Modes of the XRS7000 datasheet you shared says:

| Not every port of XRS is allowed to be configured in every mode, Table
| 25 lists the allowed modes for each port.

That table basically says that while any port can operate as a 'non-HSR,
non-PRP' interlink, only port 3 of the XRS7004 can operate as an HSR
interlink. So it is more practical to you to leave the CPU port as a
normal interlink and leave the switch push the tags.