netdev - Re: [PATCH] bonding: Always assign be16 value to vlan

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: <29611.1682116458@famine>
Date:   Fri, 21 Apr 2023 15:34:18 -0700
From:   Jay Vosburgh <jay.vosburgh@...onical.com>
To:     Vladimir Oltean <olteanv@...il.com>
cc:     Simon Horman <horms@...nel.org>, Jakub Kicinski <kuba@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Paolo Abeni <pabeni@...hat.com>,
        Andy Gospodarek <andy@...yhouse.net>, netdev@...r.kernel.org
Subject: Re: [PATCH] bonding: Always assign be16 value to vlan_proto

Vladimir Oltean <olteanv@...il.com> wrote:

>On Fri, Apr 21, 2023 at 09:01:34AM +0200, Simon Horman wrote:
>> Hi Jay and Vladimir,
>> 
>> Thanks for your review.
>> 
>> Firstly, sorry for the distraction about the VLAN_N_VID math.  I agree it
>> was incorrect. I had an out by one bug in my thought process which was
>> about 0x0fff instead of 0x1000.
>> 
>> Secondly, sorry for missing the central issue that it is a bit weird
>> to use a VID related value as a sentinel for a protocol field.
>> I agree it would be best to chose a different value.
>> 
>> In reference to the list of EtherTypes [1]. I think 0 might be ok,
>> but perhaps not ideal as technically it means a value of 0 for the
>> IEEE802.3 Length Field (although perhaps it can never mean that in this
>> context).
>> 
>> OTOH, 0xffff, is 'reserved' ([1] references RFC1701 [2]),
>> so perhaps it is a good choice.
>> 
>> In any case, I'm open to suggestions.
>> I'll probably hold off until the v6.5 cycle before reposting,
>> unless -rc8 appears next week. I'd rather not rush this one
>> given that I seem to have already got it wrong once.
>> 
>> [1] https://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xhtml#ieee-802-numbers-1
>> [2] https://www.rfc-editor.org/rfc/rfc1701.html
>
>Any value would work as long as it's not a valid VLAN protocol.
>I would #define BOND_VLAN_PROTO_NONE htons(0xffff) and use that.

	All of the above is fine with me; this isn't an urgent change.

	-J

---
	-Jay Vosburgh, jay.vosburgh@...onical.com