linux-kernel - Re: [PATCH] Alpha: Emulate unaligned LDx_L/STx

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: <e1356a60-525b-4405-ad5b-eb6e93de8fef@app.fastmail.com>
Date: Tue, 08 Apr 2025 10:37:49 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Linus Torvalds" <torvalds@...ux-foundation.org>,
 "Maciej W. Rozycki" <macro@...am.me.uk>
Cc: "Richard Henderson" <richard.henderson@...aro.org>,
 "Ivan Kokshaysky" <ink@...een.parts>, "Matt Turner" <mattst88@...il.com>,
 "John Paul Adrian Glaubitz" <glaubitz@...sik.fu-berlin.de>,
 "Magnus Lindholm" <linmag7@...il.com>,
 "Paul E. McKenney" <paulmck@...nel.org>,
 "Alexander Viro" <viro@...iv.linux.org.uk>, linux-alpha@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Alpha: Emulate unaligned LDx_L/STx_C for data consistency

On Tue, Apr 8, 2025, at 02:34, Linus Torvalds wrote:
> On Mon, 7 Apr 2025 at 13:46, Maciej W. Rozycki <macro@...am.me.uk> wrote:
>>
>>  So unless I'm proved otherwise (e.g. that all such code paths are now
>> gone from networking, which may or may not be the case: I saw IPX go but I
>> can see AppleTalk still around; or that no sub-longword accesses are ever
>> used in the relevant networking paths), I'm going to keep kernel emulation
>> in v2, because what just used to be wrapped in an unaligned LDQ/STQ pair,
>> which we trapped on and emulated, will now become an LDQ_L/STQ_C loop.
>>
>>  Do you happen to know what the situation is here?
>
> I think networking ends up using 'get_unaligned()' properly for header
> accesses these days for any of this.
>
> If you don't, some architectures will literally silently give you
> garbage back and not even fault.
>
> Admittedly that's mainly some really broken old 32-bit ARM stuff and
> hopefully it's all dead by now.

Yes, the last one doing this was EBSA110, which we removed in 2020.

> So unless you actually *see* the unaligned faults, I really think you
> shouldn't emulate them.
>
> And I'd like to know where they are if you do see them

FWIW, all the major architectures that have variants without
unaligned load/store (arm32, mips, ppc, riscv) trap and emulate
them for both user and kernel access for normal memory, but
they don't emulate it for atomic ll/sc type instructions.
These instructions also trap and kill the task on the
architectures that can do hardware unaligned access (x86
cmpxchg8b being a notable exception).

     Arnd