Created attachment 871165 [details]
simple reproduce code

On ARMv8 the stack pointer must be 16-byte aligned whenever it is used
as a base address, so program should ensure that stack is 16 byte aligned.

https://developer.arm.com/documentation/den0024/a/An-Introduction-to-the-ARMv8-Instruction-Sets/The-ARMv8-instruction-sets/Addressing

(In reply to WEI GAO from comment #1)
> Created attachment 871165 [details]
> simple reproduce code

As a side note not directly related to the issue, please note that the code sample provided is currently allocating space from BSS segment and not the stack, at least as long as the uncommented line is the one declaring the variable as static.

Thanks,
Andrea

Looks like a compiler problem. I tried with two compiler versions :

gcc (SUSE Linux) 7.5.0 (the default) - I can reproduce the issue

gcc-13 (SUSE Linux) 13.2.1 20230912 [revision b96e66fd4ef3e36983969fb8cdd1956f551a074b] - The issue disappeared

And definitely with gcc 7.5 the 'stack' variable address is not 16Bytes aligned, and on gcc 13 it is aligned.

stack variable is byte/char array, I don't think that there
is any rule that compiler should align the array in any way.

(In reply to Ivan Ivanov from comment #5)
> stack variable is byte/char array, I don't think that there
> is any rule that compiler should align the array in any way.

Exactly, also SP from gdb dump seems to be far off (0x450bf8) the usual memory range (0xfffff....) at least for EL0, it maybe something else that is corrupting  all the stuff. I'll give it a try asap to reproduce it and see why it's happening

(In reply to Ivan Ivanov from comment #5)
> stack variable is byte/char array, I don't think that there
> is any rule that compiler should align the array in any way.

Can __attribute__((__aligned__(16))) work?

The tests from Stanimir suggests that different glibc version behaves differently when it comes to clone. In fact, newer ones seem to adjust the address passed to the clone syscall:

#ltrace ./waitpid
...
clone(0x401196, 0x504082, 33555729, 0x404060)
...

#strace ./waitpid
...
clone(child_stack=0x504070, flags=CLONE_VM|CLONE_FILES|CLONE_NEWCGROUP|SIGCHLD)
...

you can see that the misaligned address passed from userspace (0x504082) has been sanitized to an aligned one (0x504070) by defect, since the stack is growing towards lower address (on most architectures). also, the address range makes sense since it has been allocated from BSS segment (see static), as follows:

#objdump -x ./waitpid | grep bss
 25 .bss          00100048  0000000000404040  0000000000404040  00003040  2**5
...

To play around a bit, you can easily tweak the topmost address of the stack array by adding e.g. one to the STACK_SIZE macro.

The advise from Takashi, i.e. adding __attribute__((__aligned__(16))) to the stack definition, should do the trick. As an alternative you can use mmap to reserve the memory to be passed as the stack, since it's page aligned, adding  MAP_STACK option for maximum portability on exotic architecture.

(In reply to Andrea della Porta from comment #8)
> The tests from Stanimir suggests that different glibc version behaves
> differently when it comes to clone. In fact, newer ones seem to adjust the
> address passed to the clone syscall:
> 
> #ltrace ./waitpid
> ...
> clone(0x401196, 0x504082, 33555729, 0x404060)
> ...
> 
> #strace ./waitpid
> ...
> clone(child_stack=0x504070,
> flags=CLONE_VM|CLONE_FILES|CLONE_NEWCGROUP|SIGCHLD)
> ...
> 
> you can see that the misaligned address passed from userspace (0x504082) has
> been sanitized to an aligned one (0x504070) by defect, since the stack is
> growing towards lower address (on most architectures). also, the address
> range makes sense since it has been allocated from BSS segment (see static),
> as follows:
> 
> #objdump -x ./waitpid | grep bss
>  25 .bss          00100048  0000000000404040  0000000000404040  00003040 
> 2**5
> ...
> 
> To play around a bit, you can easily tweak the topmost address of the stack
> array by adding e.g. one to the STACK_SIZE macro.
> 
> The advise from Takashi, i.e. adding __attribute__((__aligned__(16))) to the
> stack definition, should do the trick. As an alternative you can use mmap to
> reserve the memory to be passed as the stack, since it's page aligned,
> adding  MAP_STACK option for maximum portability on exotic architecture.

I found buf fix commit contain in glibc-2.33, so do we have plan to upgrade it?

commit 3842ba494963b1d76ad5f68b8d1e5c2279160e31
Author: Szabolcs Nagy <szabolcs.nagy@arm.com>
Date:   Tue Jun 1 09:23:40 2021 +0100

    aarch64: align stack in clone [BZ #27939]

    The AArch64 PCS requires 16 byte aligned stack.  Previously if the
    caller passed an unaligned stack to clone then the child crashed.

    Fixes bug 27939.

(In reply to Takashi Iwai from comment #7)
> (In reply to Ivan Ivanov from comment #5)
> > stack variable is byte/char array, I don't think that there
> > is any rule that compiler should align the array in any way.
> 
> Can __attribute__((__aligned__(16))) work?

Yes, this is worlking, of cource. :-) 


(In reply to WEI GAO from comment #9)

> 
> I found buf fix commit contain in glibc-2.33, so do we have plan to upgrade
> it?
> 
> commit 3842ba494963b1d76ad5f68b8d1e5c2279160e31
> Author: Szabolcs Nagy <szabolcs.nagy@arm.com>
> Date:   Tue Jun 1 09:23:40 2021 +0100
> 
>     aarch64: align stack in clone [BZ #27939]
> 
>     The AArch64 PCS requires 16 byte aligned stack.  Previously if the
>     caller passed an unaligned stack to clone then the child crashed.
> 
>     Fixes bug 27939.


Question to our glibc maintainers, I suppose.

(In reply to WEI GAO from comment #9)
> (In reply to Andrea della Porta from comment #8)
> > The tests from Stanimir suggests that different glibc version behaves
> > differently when it comes to clone. In fact, newer ones seem to adjust the
> > address passed to the clone syscall:
> > 
> > #ltrace ./waitpid
> > ...
> > clone(0x401196, 0x504082, 33555729, 0x404060)
> > ...
> > 
> > #strace ./waitpid
> > ...
> > clone(child_stack=0x504070,
> > flags=CLONE_VM|CLONE_FILES|CLONE_NEWCGROUP|SIGCHLD)
> > ...
> > 
> > you can see that the misaligned address passed from userspace (0x504082) has
> > been sanitized to an aligned one (0x504070) by defect, since the stack is
> > growing towards lower address (on most architectures). also, the address
> > range makes sense since it has been allocated from BSS segment (see static),
> > as follows:
> > 
> > #objdump -x ./waitpid | grep bss
> >  25 .bss          00100048  0000000000404040  0000000000404040  00003040 
> > 2**5
> > ...
> > 
> > To play around a bit, you can easily tweak the topmost address of the stack
> > array by adding e.g. one to the STACK_SIZE macro.
> > 
> > The advise from Takashi, i.e. adding __attribute__((__aligned__(16))) to the
> > stack definition, should do the trick. As an alternative you can use mmap to
> > reserve the memory to be passed as the stack, since it's page aligned,
> > adding  MAP_STACK option for maximum portability on exotic architecture.
> 
> I found buf fix commit contain in glibc-2.33, so do we have plan to upgrade
> it?
> 
> commit 3842ba494963b1d76ad5f68b8d1e5c2279160e31
> Author: Szabolcs Nagy <szabolcs.nagy@arm.com>
> Date:   Tue Jun 1 09:23:40 2021 +0100
> 
>     aarch64: align stack in clone [BZ #27939]
> 
>     The AArch64 PCS requires 16 byte aligned stack.  Previously if the
>     caller passed an unaligned stack to clone then the child crashed.
> 
>     Fixes bug 27939.

As Ivan already mentioned, this is not something related to the kernel so I guess this ticket has to be moved to glibc package domain.

Many thanks

Resting to default assignee.

.. moving to base system. If this is not correct, please, reassign.

Let's toss to the glibc package maintainer.

Fixed.

https://openqa.suse.de/tests/12975040 show pass, so issue can be close