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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 3 Feb 2021 23:16:34 +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:
> > > This part is not intuitive and I don't have a copy of the documents
> > > where v0 was defined. It's unfortunate this code even supports v0
> > > because AFAIK no one else uses it; but it's in here so we have to keep
> > > supporting it I guess.
> > > In v1 the tag has an eth type of 0x892f and the encapsulated
> > > supervisory frame has a type of 0x88fb. In v0 0x88fb is used for the
> > > eth type and there is no encapsulation type. So... this is correct
> > > however I compared supervisory frame generation before and after this
> > > patch for v0 and I found a problem. My changes make it add 0x88fb
> > > again later for v0 which it's not supposed to do. I'll have to fix
> > > that part somehow.
> >
> > Step 1: Sign up for HSR maintainership, it's currently orphan
> > Step 2: Delete HSRv0 support
> > Step 3: See if anyone shouts, probably not
> > Step 4: Profit.
> 
> not a bad idea however user space defaults to using v0 when doing:
> ip link add name hsr0 type hsr slave1 eth0 slave2 eth1
> 
> To use v1 you need to append "version 1".
> 
> It seems like it might be a hard sell to break the userspace default
> even if no one in their right mind is using it. Still think it's
> possible?

While HSRv0 is the default, IFLA_HSR_VERSION won't be put in the netlink
message generated by iproute2 unless you explicitly write "version 0".
So it's not like ip-link will now error out on a default RTM_NEWLINK
message, the kernel will just use a different (and more sane, according
to you) default.
Removing support for a protocol is pretty radical, but I guess if you
can make a convincing argument that nobody depends on it, it may get
accepted.