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: <20250412102304.3f74738c@pumpkin>
Date: Sat, 12 Apr 2025 10:23:04 +0100
From: David Laight <david.laight.linux@...il.com>
To: Paul Fertser <fercerpav@...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

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

If the compiler knows the value might be misaligned (eg if the structure
is __packed) then it will do multiple reads and shifts.

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.

	David

> 
> [0] https://www.catb.org/esr/structure-packing/
> 


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ