netdev - Re: [PATCH net] ethtool: Fix link extended state for big endian

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]

Message-ID: <Ye1yCtN9g/9+Sv5Q@lunn.ch>
Date:   Sun, 23 Jan 2022 16:19:38 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Moshe Tal <moshet@...dia.com>
Cc:     "David S . Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Ido Schimmel <idosch@...dia.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Amit Cohen <amcohen@...dia.com>, Jiri Pirko <jiri@...dia.com>,
        Petr Machata <petrm@...dia.com>, Gal Pressman <gal@...dia.com>,
        Tariq Toukan <tariqt@...dia.com>
Subject: Re: [PATCH net] ethtool: Fix link extended state for big endian

> The Netlink message was defined to only pass u8 and we can't change the 
> message format without causing incompatibility issues.
> So, we are assuming that values will be under 255.
> 
> Still, the compiler is storing enum as int, this isn't matter what the 
> size of the other members of the union.
> If it will be read into u8 - on BE systems the MSB will be read and so 
> it will always pass a zero.

It sounds to me like the type system is being bypassed somewhere. If
the compiler knows we are assigning an emum to a u8, it should perform
a cast and i would expect it to get it correct, independent of big or
little endian. When that u8 is assigned back to an enum, the compiler
should do another cast, and everything works out.

I assume there are no compiler warnings? The enum -> u8 is an
assignment to a smaller type, which is something you sometimes see
compilers warn about. So it might be there is an explicit cast
somewhere?

But you are saying this is not actually happening, the wrong end is
being discarded. Should we not actually be trying to find where the
type system is broken?

Maybe we as a community already do know, and i'm just ignorant. But
maybe there is nothing we can do about it, this being a KAPI? But then
the commit message should actually explain this, to avoid questions
like mine, and to spread knowledge in the community.

	Andrew