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

Message-ID: <CAFSKS=MVcQq3812us46HW2sK4uYoWxUbTvEDwH3dMF5b6bvohw@mail.gmail.com>
Date:   Mon, 8 Feb 2021 09:26:51 -0600
From:   George McCollister <george.mccollister@...il.com>
To:     Vladimir Oltean <olteanv@...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 Sat, Feb 6, 2021 at 5:43 PM Vladimir Oltean <olteanv@...il.com> wrote:
>
> 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.

If one were to set "HSR/PRP enabled" and "Port is HSR/PRP interlink
port" in HSR_CFG on the CPU port it wouldn't be possible (per the
datasheet) to enable the management or PTP timer trailer. Those modes
are intended for interlinking with a second HSR/PRP switch's
interlink. I was trying to keep this commit message somewhat switch
model agnostic and not dive into the details of the XRS7000 series. Do
you think I should describe all of this in detail in this commit
message?

-George