mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: "Thomas Weißschuh" <linux@weissschuh.net>
Cc: Sebastian Ott <sebott@redhat.com>,
	Mark Brown <broonie@kernel.org>,
	linux-kernel@vger.kernel.org
Subject: Re: aarch64 binaries using nolibc segfault before reaching the entry point
Date: Wed, 13 Sep 2023 22:58:38 +0200	[thread overview]
Message-ID: <20230913205838.GA21038@1wt.eu> (raw)
In-Reply-To: <2da5ce29-e0de-4715-aa77-453ff3cc48aa@t-8ch.de>

On Wed, Sep 13, 2023 at 10:19:00PM +0200, Thomas Weißschuh wrote:
> > All on aarch64 running fedora37 + upstream kernel. Any hints on what could
> > be borken here or how to actually fix it?
> 
> I reduced it to the following reproducer:
> 
>     $ cat test.c
>     int foo;  /* It works when deleting this variable */
>     
>     void __attribute__((weak, noreturn, optimize("Os", "omit-frame-pointer"))) _start(void)
>     {
>     	__asm__ volatile (
>     		"mov x8, 93\n"       /* NR_exit == 93 */
>     		"svc #0\n"
>     	);
>     	__builtin_unreachable();
>     }
>     
>     $ aarch64-linux-gnu-gcc -Os -static -fno-stack-protector -Wall -nostdlib test.c
>     $ ./a.out
>     Segmentation fault
> 
> Also when running under gdb the error message is:
> 
>     During startup program terminated with signal SIGSEGV, Segmentation fault.
> 
> So it seems the error already happens during loading.
> 
> Could be a compiler or kernel bug?

I tried here with gcc-11.4.0 native on an ubuntu-22.04 and using a
cross gcc-9.5 executed on another box and couldn't reproduce the issue
at all. It could be that the compiler inserts whatever, did someone
try to disassemble de resulting program to see what it looks like ?
Maybe we're even dealing with issues related to random stack alignment
that causes issues past a function call due to some garbage being placed
at the wrong place in the stack. Also, dmesg should generally report
what (and where) the segv happened. Similarly, gdb with "info reg"
and "disassemble $pc" should report some info.

In my case, I just have this:

  $ objdump -d a.out 

  a.out:     file format elf64-littleaarch64


  Disassembly of section .text:

  0000000000400144 <_start>:
    400144:       d2800ba8        mov     x8, #0x5d                       // #93
    400148:       d4000001        svc     #0x0

The kernel is a 6.2:

  $ uname -a
  Linux ampere 6.2.0-26-generic #26~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Jul 13 20:49:15 UTC 2 aarch64 aarch64 aarch64 GNU/Linux

Cheers,
Willy

  reply	other threads:[~2023-09-13 21:00 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-13 18:44 Sebastian Ott
2023-09-13 19:17 ` Mark Brown
2023-09-13 20:19 ` Thomas Weißschuh
2023-09-13 20:58   ` Willy Tarreau [this message]
2023-09-13 21:23     ` Thomas Weißschuh
2023-09-13 21:30     ` Sebastian Ott
2023-09-13 23:02   ` Thomas Weißschuh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230913205838.GA21038@1wt.eu \
    --to=w@1wt.eu \
    --cc=broonie@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@weissschuh.net \
    --cc=sebott@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®