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: <alpine.DEB.2.21.2504072042350.29566@angie.orcam.me.uk>
Date: Mon, 7 Apr 2025 21:46:26 +0100 (BST)
From: "Maciej W. Rozycki" <macro@...am.me.uk>
To: Linus Torvalds <torvalds@...ux-foundation.org>
cc: Richard Henderson <richard.henderson@...aro.org>, 
    Ivan Kokshaysky <ink@...een.parts>, Matt Turner <mattst88@...il.com>, 
    Arnd Bergmann <arnd@...db.de>, 
    John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>, 
    Magnus Lindholm <linmag7@...il.com>, 
    "Paul E. McKenney" <paulmck@...nel.org>, Al 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 Thu, 20 Feb 2025, Maciej W. Rozycki wrote:

> > Again, I don't think we care, and it works in practice, but it does
> > mean that I *really* think that:
> > 
> >  (c) you should not handle the kernel case at all.
> > 
> > If the kernel does an unaligned ld_l/st_c, that's a fundamental kernel
> > bug. Don't emulate it. Particularly when the emulation fundamentally
> > is not truly atomic wrt other accesses.
> 
>  Good point actually, I think I mentally drove myself into a dead end 
> here.  Yes, absolutely, it is not expected to happen unless we have a bug 
> in our code somewhere!

 Well, I take it back.  I knew I had something in mind while writing this 
code, just couldn't remember at the time of the reply, and I now brought 
it back at a mental relief break: it's networking.

 It's been decades ago, but I kept in memory a discussion when Alpha still 
was a thing, up to remembering it was DaveM saying we chose to use aligned 
frame/packet header accesses for performance reasons even where we don't 
know beforehand whether a given piece of networking data will or will not 
be actually aligned, so as not to penalise the common aligned case.

 Here's one reference I could track down: "TCP SYNs broken in 2.3.41", 
<https://marc.info/?l=linux-kernel&m=94927689929463> (not present on lore; 
I have the original thread of discussion with complete e-mail headers in 
my personal archive though), likely the very one I remembered.

 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?

 NB my network usage with my Alpha environment is virtually exclusively 
FDDI, and there the wrong alignment phenomena may or may not be present at 
all for the various networking protocols, owing to different link-layer 
framing (and including the Packet Request Header used by the Motorola FDDI 
chipset the way it does for the very purpose to keep things aligned).  I 
don't know offhand, my FDDI-fu is a bit dusty even in the areas I have 
already explored, and this is a new one; I've certainly not tried (to 
learn anything about) AppleTalk over FDDI (or indeed otherwise).

 All in all the lack of kernel unaligned traps in my setup and hence no 
recorded way to trigger them merely means I haven't used any of the stuff 
that used to cause them.

  Maciej