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, 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ