From: "H. Peter Anvin" <hpa@zytor.com>
To: "H. Peter Anvin" <hpa@zytor.com>,
"Jason A. Donenfeld" <Jason@zx2c4.com>,
"Peter Zijlstra (Intel)" <peterz@infradead.org>,
"Theodore Ts'o" <tytso@mit.edu>,
"Thomas Weißschuh" <thomas.weissschuh@linutronix.de>,
"Xin Li" <xin@zytor.com>,
"Andrew Cooper" <andrew.cooper3@citrix.com>,
"Andy Lutomirski" <luto@kernel.org>,
"Ard Biesheuvel" <ardb@kernel.org>,
"Borislav Petkov" <bp@alien8.de>,
"Brian Gerst" <brgerst@gmail.com>,
"Dave Hansen" <dave.hansen@linux.intel.com>,
"Ingo Molnar" <mingo@redhat.com>,
"James Morse" <james.morse@arm.com>,
"Jarkko Sakkinen" <jarkko@kernel.org>,
"Josh Poimboeuf" <jpoimboe@kernel.org>,
"Kees Cook" <kees@kernel.org>, "Nam Cao" <namcao@linutronix.de>,
"Oleg Nesterov" <oleg@redhat.com>,
"Perry Yuan" <perry.yuan@amd.com>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Thomas Huth" <thuth@redhat.com>,
"Uros Bizjak" <ubizjak@gmail.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linux-sgx@vger.kernel.org, x86@kernel.org
Subject: [PATCH 3/6] x86/entry/vdso32: remove int80_landing_pad
Date: Sun, 26 Oct 2025 15:12:03 -0700 [thread overview]
Message-ID: <20251026221208.1938173-4-hpa@zytor.com> (raw)
In-Reply-To: <20251026221208.1938173-1-hpa@zytor.com>
There is no fundamental reason for the int80_landing_pad symbol. If ip
falls within the vdso, and the vdso is moved, we should change the ip
accordingly, regardless of mode or location within the vdso. This
*currently* can only happen on 32 bits, but there isn't any reason not
to do so generically.
Note that if this is ever possible from a vdso-internal call, then the
user space stack will also needed to be adjusted (as well as the
shadow stack, if enabled.) Fortunately this is not currently the case.
At the moment, we don't even consider other threads when moving the
vdso. The assumption is that it is only used by process freeze/thaw
for migration, where this is not an issue.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
---
arch/x86/entry/vdso/vdso32/system_call.S | 1 -
arch/x86/entry/vdso/vma.c | 16 ++++++----------
arch/x86/tools/vdso2c.c | 1 -
3 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/arch/x86/entry/vdso/vdso32/system_call.S b/arch/x86/entry/vdso/vdso32/system_call.S
index 2a15634bbe75..d14eca4403c5 100644
--- a/arch/x86/entry/vdso/vdso32/system_call.S
+++ b/arch/x86/entry/vdso/vdso32/system_call.S
@@ -62,7 +62,6 @@ __kernel_vsyscall:
/* Enter using int $0x80 */
int $0x80
-SYM_INNER_LABEL(int80_landing_pad, SYM_L_GLOBAL)
/*
* Restore EDX and ECX in case they were clobbered. EBP is not
diff --git a/arch/x86/entry/vdso/vma.c b/arch/x86/entry/vdso/vma.c
index 8f98c2d7c7a9..e7fd7517370f 100644
--- a/arch/x86/entry/vdso/vma.c
+++ b/arch/x86/entry/vdso/vma.c
@@ -65,16 +65,12 @@ static vm_fault_t vdso_fault(const struct vm_special_mapping *sm,
static void vdso_fix_landing(const struct vdso_image *image,
struct vm_area_struct *new_vma)
{
- if (in_ia32_syscall() && image == &vdso32_image) {
- struct pt_regs *regs = current_pt_regs();
- unsigned long vdso_land = image->sym_int80_landing_pad;
- unsigned long old_land_addr = vdso_land +
- (unsigned long)current->mm->context.vdso;
-
- /* Fixing userspace landing - look at do_fast_syscall_32 */
- if (regs->ip == old_land_addr)
- regs->ip = new_vma->vm_start + vdso_land;
- }
+ struct pt_regs *regs = current_pt_regs();
+ unsigned long ipoffset = regs->ip -
+ (unsigned long)current->mm->context.vdso;
+
+ if (ipoffset < image->size)
+ regs->ip = new_vma->vm_start + ipoffset;
}
static int vdso_mremap(const struct vm_special_mapping *sm,
diff --git a/arch/x86/tools/vdso2c.c b/arch/x86/tools/vdso2c.c
index f84e8f8fa5fe..c81bb32b1e6c 100644
--- a/arch/x86/tools/vdso2c.c
+++ b/arch/x86/tools/vdso2c.c
@@ -79,7 +79,6 @@ struct vdso_sym required_syms[] = {
{"__kernel_vsyscall", true},
{"__kernel_sigreturn", true},
{"__kernel_rt_sigreturn", true},
- {"int80_landing_pad", true},
{"vdso32_rt_sigreturn_landing_pad", true},
{"vdso32_sigreturn_landing_pad", true},
};
--
2.51.1
next prev parent reply other threads:[~2025-10-26 22:13 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-26 22:12 [PATCH 0/6] x86/entry/vdso: cleanups for vdso build and 32-bit vdso H. Peter Anvin
2025-10-26 22:12 ` [PATCH 1/6] x86/entry/vdso: rename vdso_image_* to vdso*_image H. Peter Anvin
2025-10-26 22:12 ` [PATCH 2/6] x86/entry/vdso: refactor the vdso build H. Peter Anvin
2025-10-26 22:12 ` H. Peter Anvin [this message]
2025-10-28 6:50 ` [PATCH 3/6] x86/entry/vdso32: remove int80_landing_pad kernel test robot
2025-10-29 6:54 ` Brian Gerst
2025-10-29 14:36 ` H. Peter Anvin
2025-10-26 22:12 ` [PATCH 4/6] x86/entry/vdso32: remove SYSCALL_ENTER_KERNEL macro in sigreturn.S H. Peter Anvin
2025-10-26 22:12 ` [PATCH 5/6] x86/entry/vdso32: remove open-coded DWARF " H. Peter Anvin
2025-10-26 22:12 ` [PATCH 6/6] x86/entry/vdso32: add endbr32 to system_call.S 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=20251026221208.1938173-4-hpa@zytor.com \
--to=hpa@zytor.com \
--cc=Jason@zx2c4.com \
--cc=andrew.cooper3@citrix.com \
--cc=ardb@kernel.org \
--cc=bp@alien8.de \
--cc=brgerst@gmail.com \
--cc=dave.hansen@linux.intel.com \
--cc=james.morse@arm.com \
--cc=jarkko@kernel.org \
--cc=jpoimboe@kernel.org \
--cc=kees@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-sgx@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=namcao@linutronix.de \
--cc=oleg@redhat.com \
--cc=perry.yuan@amd.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=thomas.weissschuh@linutronix.de \
--cc=thuth@redhat.com \
--cc=tytso@mit.edu \
--cc=ubizjak@gmail.com \
--cc=x86@kernel.org \
--cc=xin@zytor.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®