linux-kernel - Re: [PATCH net-next v2] net: ncsi: Fix GCPS 64-bit member variables

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: <Z/xAHeYXfFAUpxbR@home.paul.comp>
Date: Mon, 14 Apr 2025 01:52:13 +0300
From: Paul Fertser <fercerpav@...il.com>
To: David Laight <david.laight.linux@...il.com>
Cc: kalavakunta.hari.prasad@...il.com, sam@...dozajonas.com,
        davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
        pabeni@...hat.com, horms@...nel.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, npeacock@...a.com, akozlov@...a.com,
        hkalavakunta@...a.com
Subject: Re: [PATCH net-next v2] net: ncsi: Fix GCPS 64-bit member variables

Hello David,

Many thanks for chiming in and correcting my mistake. Hari, sorry for
misleading you on the last iteration.

On Sat, Apr 12, 2025 at 10:23:04AM +0100, David Laight wrote:
> On Thu, 10 Apr 2025 13:50:58 +0300
> Paul Fertser <fercerpav@...il.com> wrote:
> 
> > Hello Hari,
> > 
> > Thank you for the patch, it looks really clean. However I have one
> > more question now.
> > 
> > On Wed, Apr 09, 2025 at 06:23:08PM -0700, kalavakunta.hari.prasad@...il.com wrote:
> > > @@ -290,11 +289,11 @@ struct ncsi_rsp_gcps_pkt {
> > >  	__be32                  tx_1023_frames; /* Tx 512-1023 bytes frames   */
> > >  	__be32                  tx_1522_frames; /* Tx 1024-1522 bytes frames  */
> > >  	__be32                  tx_9022_frames; /* Tx 1523-9022 bytes frames  */
> > > -	__be32                  rx_valid_bytes; /* Rx valid bytes             */
> > > +	__be64                  rx_valid_bytes; /* Rx valid bytes             */
> > >  	__be32                  rx_runt_pkts;   /* Rx error runt packets      */
> > >  	__be32                  rx_jabber_pkts; /* Rx error jabber packets    */
> > >  	__be32                  checksum;       /* Checksum                   */
> > > -};
> > > +}  __packed __aligned(4);  
> > 
> > This made me check the Specification and indeed somehow it happened
> > that they have forgotten to ensure natural alignment for 64-bit fields
> > (at least they cared enough to do it for 32-bit values). [0] is the
> > relevant read.
> > 
> > > +	ncs->hnc_cnt            = be64_to_cpu(rsp->cnt);  
> 
> Doesn't look related to the structure above.

This is related to the earlier change of the same struct, I just
omitted that hunk while quoting.

> > This means that while it works fine on common BMCs now (since they run
> > in 32-bit mode) the access will be trappped as unaligned on 64-bit
> > Arms which one day will be common (Aspeed AST2700, Nuvoton NPCM8XX).
> > 
> > So I guess you should be doing `be64_to_cpup(&rsp->cnt)` there.
> 
> That is is the one that fails - the compiler is likely to warn about
> taking the address of a member of a packed structure.

Indeed I was confused. I was reading just
include/linux/byteorder/generic.h and expecting some kind of tricky
behaviour from the compiler (for the sake of optimisation as usual)
and wasn't aware of [0]. Taking address of such a field would indeed
produce a warning with -Waddress-of-packed-member.

> IIRC it is enough to mark the member rx_valid_bytes __packed.
> That removes the padding before it and the compiler will then assume
> it is 4-byte aligned.

The problem is that this struct is full of members that happen to be
unaligned (as the NC-SI standard specified that), it's used to unpack
a response packet returned by networking interface, so ratehr than
having every __be64 value there __packed it's cleaner to have the
attribute specified for the whole struct I guess.

Thanks again!


[0] https://www.kernel.org/doc/html/latest/core-api/unaligned-memory-access.html#code-that-does-not-cause-unaligned-access