Re: possible bug in setjmp implementation for ppc64

[Rich Felker <dalias@libc.org>]

On Mon, Jul 31, 2017 at 10:06:51PM +0200, felix.winkelmann@bevuta.com wrote:
> Hi!
> 
> I think I may have come across a bug in musl on PPC64(le), and the folks
> on the #musl IRC channel directed me here. I'm not totally sure whether
> the problem is caused by a my misunderstanding of C library functions or whether
> it is a plain bug in the musl implementation of setjmp(3).
> 
> In out project[1] we use setjmp to establish a global trampoline
> and allocate small objects on the stack using alloca (see [2] for
> more information about the compiliation strategy used). I was able to reduce
> the code that crashes to the following:
> 
> ---
> #include <stdio.h>
> #include <alloca.h>
> #include <setjmp.h>
> #include <string.h>
> #include <stdlib.h>
> 
> jmp_buf jb;
> 
> int foo = 99;
> int c = 0;
> 
> void bar()
> {
>   c++;
>   longjmp(jb, 1);
> }
> 
> int main()
> {
>   setjmp(jb);
>   char *p = alloca(256);
>   memset(p, 0, 256);
>   printf("%d\n", foo);
> 
>   if(c < 10) bar();
> 
>   exit(0);
> }
> ---
> 
> When executing the longjmp, the code that restores $r2 (TOC) after the call
> to setjmp reads invalid data, because the memset apparently clobbered
> the stack frame - i.e. the pointer returned be alloca points into a part
> of the stack frame that is still in use.
> 
> I tried this on arm, x86_64 and ppc64 with glibc and it seems to work fine,
> but crashes when linked with musl (running Alpine Linux on a VM)
> 
> If you need more information, please feel free to ask. You can also keep
> me CC'd, since I'd be interested in knowing more about the details.

It looks to me like we have a bug here, but it's one where I or
someone else needs to read and understand the PPC64 ELFv2 ABI document
to fully understand what's going on and make a fix. I'll try to get to
it soon, or I'm happy if someone else wants to. I don't just want to
cargo-cult whatever glibc is doing, though; a fix should be
accompanied by an understanding of why it's right.

Rich