Re: [PATCH] Alpha: Emulate unaligned LDx_L/STx_C for data consistency

[Eric W. Biederman]

"Arnd Bergmann" <arnd@xxxxxxxx> writes:

> On Tue, Apr 8, 2025, at 02:34, Linus Torvalds wrote:
>> On Mon, 7 Apr 2025 at 13:46, Maciej W. Rozycki <macro@xxxxxxxxxxx> 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

I was nerd sniped by this so I took a look.

I have a distinct memory that even the ipv4 stack can generate unaligned
loads.  Looking at the code in net/ipv4/ip_input.c:ip_rcv_finish_core
there are several unprotected accesses to iph->daddr.

Which means that if the lower layers ever give something that is not 4
byte aligned for ipv4 just reading the destination address will be an
unaligned read.

There are similar unprotected accesses to the ipv6 destination address
but it is declared as an array of bytes.  So that address can not
be misaligned.

There is a theoretical path through 802.2 that adds a 3 byte sap
header that could cause problems.  We have LLC_SAP_IP defined
but I don't see anything calling register_8022_client that would
be needed to hook that up to the ipv4 stack.

As long as the individual ethernet drivers have the hardware deliver
packets 2 bytes into an aligned packet buffer the 14 byte ethernet
header will end on a 16 byte aligned location, I don't think there
is a way to trigger unaligned behavior with ipv4 or ipv6.

Hmm.  Looking appletalk appears to be built on top of SNAP.
So after the ethernet header processing the code goes through
net/llc/llc_input.c:llc_rcv and then net/802/snap_rcv before
reaching any of the appletalk protocols.

I think the common case for llc would be 3 bytes + 5 bytes for snap,
for 8 bytes in the common case.  But the code seems to be reading
4 or 5 bytes for llc so I am confused.  In either case it definitely
appears there are cases where the ethernet headers before appletalk
can be an odd number of bytes which has the possibility of unaligning
everything.

Both of the appletalk protocols appear to make unguarded 16bit reads
from their headers.  So having a buffer that is only 1 byte aligned
looks like it will definitely be a problem.

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

I don't see anything that would get atomics involved in the networking
stack.  No READ_ONCE on packet data or anything like that.  I believe
that is fairly fundamental as well.  Whatever is processing a packet is
the only code processing that packet.

So I would be very surprised if the kernel needed emulation of any
atomics, just emulation of normal unaligned reads.  I haven't looked to
see if the transmission paths do things that will result in unaligned
writes.

Eric