Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1402325 > unrolled thread

[PATCHv9 0/2] mremap vDSO for 32-bit

Back to article view | Back to linux.kernel

Contents

  [PATCHv9 0/2] mremap vDSO for 32-bit Dmitry Safonov <dsafonov@virtuozzo.com> - 2016-05-17 14:40 +0200
    [PATCHv9 1/2] x86/vdso: add mremap hook to vm_special_mapping Dmitry Safonov <dsafonov@virtuozzo.com> - 2016-05-17 14:50 +0200
    Re: [PATCHv9 0/2] mremap vDSO for 32-bit Dmitry Safonov <dsafonov@virtuozzo.com> - 2016-05-19 13:30 +0200

#1402325 — [PATCHv9 0/2] mremap vDSO for 32-bit

The first patch adds support of mremapping 32-bit vDSO.
One could move vDSO vma before this patch, but fast syscalls
on moved vDSO hasn't been working. It's because of code that
relies on mm->context.vdso pointer.
So all this code is just fixup for that pointer on moving.
(Also adds preventing for splitting vDSO vma).
As Andy notted, 64-bit vDSO mremap also has worked only by a chance
before this patches.
The second patch adds a test for the new functionality.

I need possibility to move vDSO in CRIU - on restore we need
to choose vma's position:
- if vDSO blob of restoring application is the same as the kernel has,
  we need to move it on the same place;
- if it differs, we need to choose place that wasn't tooken by other
  vma of restoring application and than add jump trampolines to it
  from the place of vDSO in restoring application.

CRIU code now relies on possibility on x86_64 to mremap vDSO.
Without this patch that may be broken in future.
And as I work on C/R of compatible 32-bit applications on x86_64,
I need mremap to work also for 32-bit vDSO. Which does not work,
because of context.vdso pointer mentioned above. 

Changes:
v9: Added cover-letter with changelog and reasons for patches
v8: Add WARN_ON_ONCE on current->mm != new_vma->vm_mm;
    run test for x86_64 too;
    removed fixed VDSO_SIZE - check EINVAL mremap return for partial remapping
v7: Build fix
v6: Moved vdso_image_32 check and fixup code into vdso_fix_landing function
    with ifdefs around
v5: As Andy suggested, add a check that new_vma->vm_mm and current->mm are
    the same, also check not only in_ia32_syscall() but image == &vdso_image_32;
    added test for mremapping vDSO
v4: Drop __maybe_unused & use image from mm->context instead vdso_image_32
v3: As Andy suggested, return EINVAL in case of splitting vdso blob on mremap;
    used is_ia32_task instead of ifdefs 
v2: Added __maybe_unused for pt_regs in vdso_mremap

Dmitry Safonov (2):
  x86/vdso: add mremap hook to vm_special_mapping
  selftest/x86: add mremap vdso test

 arch/x86/entry/vdso/vma.c                      | 47 ++++++++++--
 include/linux/mm_types.h                       |  3 +
 mm/mmap.c                                      | 10 +++
 tools/testing/selftests/x86/Makefile           |  2 +-
 tools/testing/selftests/x86/test_mremap_vdso.c | 99 ++++++++++++++++++++++++++
 5 files changed, 155 insertions(+), 6 deletions(-)
 create mode 100644 tools/testing/selftests/x86/test_mremap_vdso.c

-- 
2.8.0

[toc] | [next] | [standalone]

#1402327 — [PATCHv9 1/2] x86/vdso: add mremap hook to vm_special_mapping

Add possibility for userspace 32-bit applications to move
vdso mapping. Previously, when userspace app called
mremap for vdso, in return path it would land on previous
address of vdso page, resulting in segmentation violation.
Now it lands fine and returns to userspace with remapped vdso.
This will also fix context.vdso pointer for 64-bit, which does not
affect the user of vdso after mremap by now, but this may change.

As suggested by Andy, return EINVAL for mremap that splits vdso image.

Renamed and moved text_mapping structure declaration inside
map_vdso, as it used only there and now it complement
vvar_mapping variable.

There is still problem for remapping vdso in glibc applications:
linker relocates addresses for syscalls on vdso page, so
you need to relink with the new addresses. Or the next syscall
through glibc may fail:
  Program received signal SIGSEGV, Segmentation fault.
  #0  0xf7fd9b80 in __kernel_vsyscall ()
  #1  0xf7ec8238 in _exit () from /usr/lib32/libc.so.6

Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Acked-by: Andy Lutomirski <luto@kernel.org>
---
 arch/x86/entry/vdso/vma.c | 47 ++++++++++++++++++++++++++++++++++++++++++-----
 include/linux/mm_types.h  |  3 +++
 mm/mmap.c                 | 10 ++++++++++
 3 files changed, 55 insertions(+), 5 deletions(-)

diff --git a/arch/x86/entry/vdso/vma.c b/arch/x86/entry/vdso/vma.c
index ab220ac9b3b9..3329844e3c43 100644
--- a/arch/x86/entry/vdso/vma.c
+++ b/arch/x86/entry/vdso/vma.c
@@ -12,6 +12,7 @@
 #include <linux/random.h>
 #include <linux/elf.h>
 #include <linux/cpu.h>
+#include <linux/ptrace.h>
 #include <asm/pvclock.h>
 #include <asm/vgtod.h>
 #include <asm/proto.h>
@@ -97,10 +98,40 @@ static int vdso_fault(const struct vm_special_mapping *sm,
 	return 0;
 }
 
-static const struct vm_special_mapping text_mapping = {
-	.name = "[vdso]",
-	.fault = vdso_fault,
-};
+static void vdso_fix_landing(const struct vdso_image *image,
+		struct vm_area_struct *new_vma)
+{
+#if defined CONFIG_X86_32 || defined CONFIG_IA32_EMULATION
+	if (in_ia32_syscall() && image == &vdso_image_32) {
+		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;
+	}
+#endif
+}
+
+static int vdso_mremap(const struct vm_special_mapping *sm,
+		struct vm_area_struct *new_vma)
+{
+	unsigned long new_size = new_vma->vm_end - new_vma->vm_start;
+	const struct vdso_image *image = current->mm->context.vdso_image;
+
+	if (image->size != new_size)
+		return -EINVAL;
+
+	if (WARN_ON_ONCE(current->mm != new_vma->vm_mm))
+		return -EFAULT;
+
+	vdso_fix_landing(image, new_vma);
+	current->mm->context.vdso = (void __user *)new_vma->vm_start;
+
+	return 0;
+}
 
 static int vvar_fault(const struct vm_special_mapping *sm,
 		      struct vm_area_struct *vma, struct vm_fault *vmf)
@@ -151,6 +182,12 @@ static int map_vdso(const struct vdso_image *image, bool calculate_addr)
 	struct vm_area_struct *vma;
 	unsigned long addr, text_start;
 	int ret = 0;
+
+	static const struct vm_special_mapping vdso_mapping = {
+		.name = "[vdso]",
+		.fault = vdso_fault,
+		.mremap = vdso_mremap,
+	};
 	static const struct vm_special_mapping vvar_mapping = {
 		.name = "[vvar]",
 		.fault = vvar_fault,
@@ -185,7 +222,7 @@ static int map_vdso(const struct vdso_image *image, bool calculate_addr)
 				       image->size,
 				       VM_READ|VM_EXEC|
 				       VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
-				       &text_mapping);
+				       &vdso_mapping);
 
 	if (IS_ERR(vma)) {
 		ret = PTR_ERR(vma);
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index d553855503e6..ab5862b33a7b 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -592,6 +592,9 @@ struct vm_special_mapping {
 	int (*fault)(const struct vm_special_mapping *sm,
 		     struct vm_area_struct *vma,
 		     struct vm_fault *vmf);
+
+	int (*mremap)(const struct vm_special_mapping *sm,
+		     struct vm_area_struct *new_vma);
 };
 
 enum tlb_flush_reason {
diff --git a/mm/mmap.c b/mm/mmap.c
index d3d9a94ca031..9979109cf083 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2943,9 +2943,19 @@ static const char *special_mapping_name(struct vm_area_struct *vma)
 	return ((struct vm_special_mapping *)vma->vm_private_data)->name;
 }
 
+static int special_mapping_mremap(struct vm_area_struct *new_vma)
+{
+	struct vm_special_mapping *sm = new_vma->vm_private_data;
+
+	if (sm->mremap)
+		return sm->mremap(sm, new_vma);
+	return 0;
+}
+
 static const struct vm_operations_struct special_mapping_vmops = {
 	.close = special_mapping_close,
 	.fault = special_mapping_fault,
+	.mremap = special_mapping_mremap,
 	.name = special_mapping_name,
 };
 
-- 
2.8.0

[toc] | [prev] | [next] | [standalone]

#1403655

On 05/17/2016 03:13 PM, Dmitry Safonov wrote:
> The first patch adds support of mremapping 32-bit vDSO.
> One could move vDSO vma before this patch, but fast syscalls
> on moved vDSO hasn't been working. It's because of code that
> relies on mm->context.vdso pointer.
> So all this code is just fixup for that pointer on moving.
> (Also adds preventing for splitting vDSO vma).
> As Andy notted, 64-bit vDSO mremap also has worked only by a chance
> before this patches.
> The second patch adds a test for the new functionality.
>
> I need possibility to move vDSO in CRIU - on restore we need
> to choose vma's position:
> - if vDSO blob of restoring application is the same as the kernel has,
>   we need to move it on the same place;
> - if it differs, we need to choose place that wasn't tooken by other
>   vma of restoring application and than add jump trampolines to it
>   from the place of vDSO in restoring application.
>
> CRIU code now relies on possibility on x86_64 to mremap vDSO.
> Without this patch that may be broken in future.
> And as I work on C/R of compatible 32-bit applications on x86_64,
> I need mremap to work also for 32-bit vDSO. Which does not work,
> because of context.vdso pointer mentioned above.
>
> Changes:
> v9: Added cover-letter with changelog and reasons for patches
> v8: Add WARN_ON_ONCE on current->mm != new_vma->vm_mm;
>     run test for x86_64 too;
>     removed fixed VDSO_SIZE - check EINVAL mremap return for partial remapping
> v7: Build fix
> v6: Moved vdso_image_32 check and fixup code into vdso_fix_landing function
>     with ifdefs around
> v5: As Andy suggested, add a check that new_vma->vm_mm and current->mm are
>     the same, also check not only in_ia32_syscall() but image == &vdso_image_32;
>     added test for mremapping vDSO
> v4: Drop __maybe_unused & use image from mm->context instead vdso_image_32
> v3: As Andy suggested, return EINVAL in case of splitting vdso blob on mremap;
>     used is_ia32_task instead of ifdefs
> v2: Added __maybe_unused for pt_regs in vdso_mremap

Ping?

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web