mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Gow <davidgow@google.com>
To: Benjamin Berg <benjamin.berg@intel.com>,
	Johannes Berg <johannes@sipsolutions.net>
Cc: linux-um@lists.infradead.org, kunit-dev@googlegroups.com,
	 linux-kernel@vger.kernel.org, David Gow <davidgow@google.com>
Subject: [PATCH v2] um: Fix misaligned stack in stub_exe
Date: Tue, 22 Oct 2024 18:10:17 +0800	[thread overview]
Message-ID: <20241022101016.2565249-2-davidgow@google.com> (raw)

The stub_exe could segfault when built with some compilers (e.g. gcc
13.2.0), as SSE instructions which relied on stack alignment could be
generated, but the stack was misaligned.

This seems to be due to the __start entry point being run with a 16-byte
aligned stack, but the x86_64 SYSV ABI wanting the stack to be so
aligned _before_ a function call (so it is misaligned when the function
is entered due to the return address being pushed). The function
prologue then realigns it. Because the entry point is never _called_,
and hence there is no return address, the prologue is therefore actually
misaligning it, and causing the generated movaps instructions to
SIGSEGV. This results in the following error:
start_userspace : expected SIGSTOP, got status = 139

Force the compiler to emit code to re-align the stack in real_init(), so
that the generated SSE code doesn't crash. This isn't necessarily the
_correct_ way of solving the problem, but it avoids the need to rewrite
__start in assembly for each architecture for now.

Fixes: 32e8eaf263d9 ("um: use execveat to create userspace MMs")
Signed-off-by: David Gow <davidgow@google.com>
---

Changes since v1:
https://lore.kernel.org/linux-um/20241017231007.1500497-2-davidgow@google.com/
- Use force_arg_align_pointer on real_init() instead of naked on
  __start, which works with clang.

 arch/um/kernel/skas/stub_exe.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

---
diff --git a/arch/um/kernel/skas/stub_exe.c b/arch/um/kernel/skas/stub_exe.c
index 04f75c577f1a..50fded2384e6 100644
--- a/arch/um/kernel/skas/stub_exe.c
+++ b/arch/um/kernel/skas/stub_exe.c
@@ -6,7 +6,7 @@
 
 void _start(void);
 
-noinline static void real_init(void)
+noinline __attribute__((force_align_arg_pointer)) static void real_init(void)
 {
 	struct stub_init_data init_data;
 	unsigned long res;
-- 
2.47.0.105.g07ac214952-goog


             reply	other threads:[~2024-10-22 10:10 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-22 10:10 David Gow [this message]
2024-10-22 10:12 ` Johannes Berg

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=20241022101016.2565249-2-davidgow@google.com \
    --to=davidgow@google.com \
    --cc=benjamin.berg@intel.com \
    --cc=johannes@sipsolutions.net \
    --cc=kunit-dev@googlegroups.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-um@lists.infradead.org \
    /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®