linux-kernel - Re: [RFC v3 1/5] documentation: Discourage alignment assumptions

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: <29188dc5-32a3-28f9-b488-26cca713e070@linux-m68k.org>
Date: Thu, 16 Oct 2025 17:53:05 +1100 (AEDT)
From: Finn Thain <fthain@...ux-m68k.org>
To: David Laight <david.laight.linux@...il.com>
cc: Peter Zijlstra <peterz@...radead.org>, Will Deacon <will@...nel.org>, 
    Andrew Morton <akpm@...ux-foundation.org>, 
    Boqun Feng <boqun.feng@...il.com>, Jonathan Corbet <corbet@....net>, 
    Mark Rutland <mark.rutland@....com>, Arnd Bergmann <arnd@...db.de>, 
    linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org, 
    Geert Uytterhoeven <geert@...ux-m68k.org>, linux-m68k@...r.kernel.org, 
    linux-doc@...r.kernel.org
Subject: Re: [RFC v3 1/5] documentation: Discourage alignment assumptions


On Wed, 15 Oct 2025, David Laight wrote:

> 
> There are several separate alignments:
> - The alignment the cpu needs, for most x86 instructions this is 1 byte [1].
>   Many RISC cpu require 'word' alignment (for some definition of 'word').
>   A problematic case is data that crosses page boundaries.
> - The alignment the compiler uses for structure members; returned by _Alignof().
>   m68k only 16bit aligns 32bit values.
> - The 'preferred' alignment returned by __alignof__().
>   32bit x86 returns 8 for 64bit types even though the ABI only 4-byte aligns them.
> - The 'natural' alignment based on the size of the item.
>   I'd guess that 'complex double' (if supported) may only be 8 byte aligned.
> 

Those distinctions could be useful in a discussion about memory 
efficiency. But this document is concerned with avoiding a performance 
penalty -- it's entirely unconcerned with over-alignment and memory waste.
Hence, "aligned" is used as shorthand for "naturally aligned".

The ambiguity in this document (and my proposed change) stems from using 
the word architecture to cover ABI, platform, CPU, ISA etc.
I can improve upon that.

> What normally matters is the ABI alignment for structure members.
> If you mark anything 'packed' the compiler will generate shifts and masks (etc)
> to get working code.
> Taking the address of an item in a packed structure generates a warning
> for very good reason. 
> 

I believe the problem with 'packed' is already covered in this document.

> [1] I've fallen foul of gcc deciding to 'vectorise' a loop and then having
> it crash because the buffer address was misaligned.
> Nasty because the code worked in initial testing and I expected the loop
> (32bit adds of a buffer) to work fine even when misaligned.
> 

I think that pitfall is already discussed also, along with a remedy.

There is also this,

    ... for standard structure types you can always rely on the compiler 
    to pad structures so that accesses to fields are suitably aligned 
    (assuming you do not cast the field to a type of different length).

So it seems to be fairly comprehensive but I may be missing something (?)