linux-kernel - Re: [RFC v2 3/3] atomic: Add alignment check to instrumented atomic operations

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: <3d3b1a8f-7f60-f03b-f13e-089f605961e6@linux-m68k.org>
Date: Tue, 23 Sep 2025 16:39:31 +1000 (AEST)
From: Finn Thain <fthain@...ux-m68k.org>
To: Arnd Bergmann <arnd@...db.de>
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>, linux-kernel@...r.kernel.org, 
    Linux-Arch <linux-arch@...r.kernel.org>, 
    Geert Uytterhoeven <geert@...ux-m68k.org>, linux-m68k@...r.kernel.org
Subject: Re: [RFC v2 3/3] atomic: Add alignment check to instrumented atomic
 operations


On Mon, 22 Sep 2025, Arnd Bergmann wrote:

> 
> I don't think automated transformation is going to work well here, as 
> you may not want the same approach in each case, depending on what the 
> code is:
> 
> - it may be enough to annotate a single member as packed in order to 
>   make the entire structure compatible

Right, and that's the only transformation I mentioned.

> - some structures may have lots of misaligned members, but no holes, so 
>   a global __attribute__((packed, aligned(2))) on that struct is cleaner

That simplification should be amenable to further automation, if the first 
transformation is.

> - if there are holes, some strategic additions of explicit padding can 
>   be cleaner than annotating each misaligned member.

It's a matter of taste.

> - automation won't be able to tell whether a structure is ABI relevant 
>   or not

Right. That's why I said the list of struct members would need to be 
"manually pared down". But even that task may be too large to be feasible.

> - similarly, many files are not going to be interesting for m68k. E.g. 
>   if drivers/infiniband has an ABI that is different for -malign-int, 
>   that can likely be ignored because nobody cares in practice.
> 

Right. That's why I advocated running the plug-in on a "normal build" not 
a contrived mass of #includes and structs.