All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Ingo Molnar <mingo@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Andy Lutomirski <luto@kernel.org>, Borislav Petkov <bp@alien8.de>,
	"H. Peter Anvin" <hpa@zytor.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: [PATCH v3 1/4] x86/syscall: sign-extend system calls on entry to int
Date: Fri, 14 May 2021 18:10:12 -0700	[thread overview]
Message-ID: <20210515011015.2707542-2-hpa@zytor.com> (raw)
In-Reply-To: <20210515011015.2707542-1-hpa@zytor.com>

From: "H. Peter Anvin (Intel)" <hpa@zytor.com>

Right now, *some* code will treat e.g. 0x00000001_00000001 as a system
call and some will not. Some of the code, notably in ptrace and
seccomp, will treat 0x00000001_ffffffff as a system call and some will
not.

This is visible to the user: for example, the syscall_numbering_64
test fails if run under strace, because as strace uses ptrace, it ends
up clobbering the upper half of the 64-bit system call number.

The arch-independent code all assumes that a system call is "int" that
the value -1 specifically and not just any negative value is used for
a non-system call. This is the case on x86 as well when
arch-independent code is involved. The arch-independent API is
defined/documented (but not *implemented*!) in
<asm-generic/syscall.h>.

This is an ABI change, but is in fact a revert to the original x86-64
ABI. The original assembly entry code would zero-extend the system
call number; this patch uses sign extend to be explicit that this is
treated as a signed number (although in practice it makes no
difference, of course) and to avoid people getting the idea of
"optimizing" it, as has happened on at least two(!) separate
occasions.

Do not store the extended value into regs->orig_ax, however: on
x86-64, the ABI is that the callee is responsible for extending
parameters, so only examining the lower 32 bits is fully consistent
with any "int" argument to any system call, e.g. regs->di for
write(2). The full value of %rax on entry to the kernel is thus still
available.

Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
---
 arch/x86/entry/entry_64.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index 1d9db15fdc69..85f04ea0e368 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -108,7 +108,7 @@ SYM_INNER_LABEL(entry_SYSCALL_64_after_hwframe, SYM_L_GLOBAL)
 
 	/* IRQs are off. */
 	movq	%rsp, %rdi
-	movq	%rax, %rsi
+	movslq	%eax, %rsi
 	call	do_syscall_64		/* returns with IRQs disabled */
 
 	/*
-- 
2.31.1


  reply	other threads:[~2021-05-15  1:11 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-15  1:10 [RFC v3 PATCH 0/4] x86/syscall: use int for x86-64 system calls H. Peter Anvin
2021-05-15  1:10 ` H. Peter Anvin [this message]
2021-05-16  7:48   ` [PATCH v3 1/4] x86/syscall: sign-extend system calls on entry to int Ingo Molnar
2021-05-17 20:23     ` H. Peter Anvin
2021-05-15  1:10 ` [PATCH v3 2/4] x86/syscall: update and extend selftest syscall_numbering_64 H. Peter Anvin
2021-05-16  7:52   ` Ingo Molnar
2021-05-18  0:26     ` H. Peter Anvin
2021-05-18 15:04     ` H. Peter Anvin
2021-05-15  1:10 ` [PATCH v3 3/4] x86/syscall: treat out of range and gap system calls the same H. Peter Anvin
2021-05-15  1:10 ` [PATCH v3 4/4] x86/syscall: use int everywhere for system call numbers H. Peter Anvin
2021-05-15 15:37   ` Andy Lutomirski
2021-05-15 17:41     ` H. Peter Anvin
2021-05-15 17:42     ` H. Peter Anvin
     [not found]       ` <2ebf1bac-93c1-4b7f-add4-4ede3c149b52@www.fastmail.com>
2021-05-15 21:07         ` H. Peter Anvin

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=20210515011015.2707542-2-hpa@zytor.com \
    --to=hpa@zytor.com \
    --cc=bp@alien8.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.