arm64: Support VDSO remapping

PATCH In review Christopher Covington 5 participants 15 messages Nov 25, 2015 – May 4, 2016

Subsystems (7)

Memory management Arm Qualcomm mailing list PowerPC arm64 +3 more subsystems

lore

Share & tools

lore

Christopher Covington

author

2015-11-25 12:49 UTC #0 lore raw

PATCH 1/1 arm64: Support VDSO remapping

Some applications such as Checkpoint/Restore In Userspace (CRIU) remap and unmap the VDSO. Add support for this to the AArch64 kernel by copying in the PowerPC code with slight modifications.

Signed-off-by Christopher Covington <[email protected]>

---
 arch/arm64/include/asm/Kbuild          |  1 -
 arch/arm64/include/asm/mm-arch-hooks.h | 28 ++++++++++++++++++++++++++++
 arch/arm64/include/asm/mmu_context.h   | 23 ++++++++++++++++++++++-
 3 files changed, 50 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm64/include/asm/mm-arch-hooks.h

arch/arm64/include/asm/Kbuild +0 -1

index 70fd9ff..b112a39 100644
@@ -25,7 +25,6 @@ generic-y += kvm_para.h
 generic-y += local.h
 generic-y += local64.h
 generic-y += mcs_spinlock.h
-generic-y += mm-arch-hooks.h
 generic-y += mman.h
 generic-y += msgbuf.h
 generic-y += msi.h

arch/arm64/include/asm/mm-arch-hooks.h new file +28 -0

new file mode 100644
index 0000000..e6923fb
@@ -0,0 +1,28 @@
+/*
+ * Architecture specific mm hooks
+ *
+ * Copyright (C) 2015, IBM Corporation
+ * Author: Laurent Dufour <[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __ASM_MM_ARCH_HOOKS_H
+#define __ASM_MM_ARCH_HOOKS_H
+
+static inline void arch_remap(struct mm_struct *mm,
+			      unsigned long old_start, unsigned long old_end,
+			      unsigned long new_start, unsigned long new_end)
+{
+	/*
+	 * mremap() doesn't allow moving multiple vmas so we can limit the
+	 * check to old_start == vdso_base.
+	 */
+	if ((void *)old_start == mm->context.vdso)
+		mm->context.vdso = (void *)new_start;
+}
+#define arch_remap arch_remap
+
+#endif /* __ASM_MM_ARCH_HOOKS_H */

arch/arm64/include/asm/mmu_context.h +22 -1

index 2416578..9fe0773 100644
@@ -24,7 +24,6 @@
 
 #include <asm/cacheflush.h>
 #include <asm/proc-fns.h>
-#include <asm-generic/mm_hooks.h>
 #include <asm/cputype.h>
 #include <asm/pgtable.h>

@@ -147,4 +146,26 @@ switch_mm(struct mm_struct *prev, struct mm_struct *next,
 #define deactivate_mm(tsk,mm)	do { } while (0)
 #define activate_mm(prev,next)	switch_mm(prev, next, NULL)
 
+static inline void arch_dup_mmap(struct mm_struct *oldmm,
+				      struct mm_struct *mm)
+{
+}
+
+static inline void arch_exit_mmap(struct mm_struct *mm)
+{
+}
+
+static inline void arch_unmap(struct mm_struct *mm,
+			      struct vm_area_struct *vma,
+			      unsigned long start, unsigned long end)
+{
+	if ((void *)start <= mm->context.vdso && mm->context.vdso < (void *)end)
+		mm->context.vdso = NULL;
+}
+
+static inline void arch_bprm_mm_init(struct mm_struct *mm,
+				     struct vm_area_struct *vma)
+{
+}
+
 #endif

Signature · 3 lines

Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Will Deacon

2015-12-02 12:19 UTC #1 lore raw

Hi Christopher,

Quoted 85 lines · Christopher Covington

Some applications such as Checkpoint/Restore In Userspace (CRIU) remap and unmap the VDSO. Add support for this to the AArch64 kernel by copying in the PowerPC code with slight modifications.

Signed-off-by Christopher Covington <[email protected]>

---
 arch/arm64/include/asm/Kbuild          |  1 -
 arch/arm64/include/asm/mm-arch-hooks.h | 28 ++++++++++++++++++++++++++++
 arch/arm64/include/asm/mmu_context.h   | 23 ++++++++++++++++++++++-
 3 files changed, 50 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm64/include/asm/mm-arch-hooks.h

arch/arm64/include/asm/Kbuild +0 -1

index 70fd9ff..b112a39 100644
@@ -25,7 +25,6 @@ generic-y += kvm_para.h
 generic-y += local.h
 generic-y += local64.h
 generic-y += mcs_spinlock.h
-generic-y += mm-arch-hooks.h
 generic-y += mman.h
 generic-y += msgbuf.h
 generic-y += msi.h

arch/arm64/include/asm/mm-arch-hooks.h new file +28 -0

new file mode 100644
index 0000000..e6923fb
@@ -0,0 +1,28 @@
+/*
+ * Architecture specific mm hooks
+ *
+ * Copyright (C) 2015, IBM Corporation
+ * Author: Laurent Dufour <[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __ASM_MM_ARCH_HOOKS_H
+#define __ASM_MM_ARCH_HOOKS_H
+
+static inline void arch_remap(struct mm_struct *mm,
+			      unsigned long old_start, unsigned long old_end,
+			      unsigned long new_start, unsigned long new_end)
+{
+	/*
+	 * mremap() doesn't allow moving multiple vmas so we can limit the
+	 * check to old_start == vdso_base.
+	 */
+	if ((void *)old_start == mm->context.vdso)
+		mm->context.vdso = (void *)new_start;
+}
+#define arch_remap arch_remap
+
+#endif /* __ASM_MM_ARCH_HOOKS_H */

arch/arm64/include/asm/mmu_context.h +11 -1

index 2416578..9fe0773 100644
@@ -24,7 +24,6 @@
 
 #include <asm/cacheflush.h>
 #include <asm/proc-fns.h>
-#include <asm-generic/mm_hooks.h>
 #include <asm/cputype.h>
 #include <asm/pgtable.h>

@@ -147,4 +146,26 @@ switch_mm(struct mm_struct *prev, struct mm_struct *next,
 #define deactivate_mm(tsk,mm)	do { } while (0)
 #define activate_mm(prev,next)	switch_mm(prev, next, NULL)
 
+static inline void arch_dup_mmap(struct mm_struct *oldmm,
+				      struct mm_struct *mm)
+{
+}
+
+static inline void arch_exit_mmap(struct mm_struct *mm)
+{
+}
+
+static inline void arch_unmap(struct mm_struct *mm,
+			      struct vm_area_struct *vma,

arch/arm64/include/asm/mmu_context.h switch_mm(struct mm_struct *prev, struct mm_struct *next, · line 169

Quoted 10 lines

arch/arm64/include/asm/mmu_context.h +10 -0

+			      unsigned long start, unsigned long end)
+{
+	if ((void *)start <= mm->context.vdso && mm->context.vdso < (void *)end)
+		mm->context.vdso = NULL;
+}
+
+static inline void arch_bprm_mm_init(struct mm_struct *mm,
+				     struct vm_area_struct *vma)
+{
+}

This is virtually identical to the PowerPC implementation, afaict. Any chance we could move this to core code and define some generic vdso accessors for the mm?

Will

Christopher Covington

author

2015-12-03 18:05 UTC #2 lore raw

Quoted 94 lines · Will Deacon

Hi Christopher,

Quoted 91 lines · Christopher Covington

Some applications such as Checkpoint/Restore In Userspace (CRIU) remap and unmap the VDSO. Add support for this to the AArch64 kernel by copying in the PowerPC code with slight modifications.

Signed-off-by Christopher Covington <[email protected]>

---
 arch/arm64/include/asm/Kbuild          |  1 -
 arch/arm64/include/asm/mm-arch-hooks.h | 28 ++++++++++++++++++++++++++++
 arch/arm64/include/asm/mmu_context.h   | 23 ++++++++++++++++++++++-
 3 files changed, 50 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm64/include/asm/mm-arch-hooks.h

arch/arm64/include/asm/Kbuild +0 -1

index 70fd9ff..b112a39 100644
@@ -25,7 +25,6 @@ generic-y += kvm_para.h
 generic-y += local.h
 generic-y += local64.h
 generic-y += mcs_spinlock.h
-generic-y += mm-arch-hooks.h
 generic-y += mman.h
 generic-y += msgbuf.h
 generic-y += msi.h

arch/arm64/include/asm/mm-arch-hooks.h new file +28 -0

new file mode 100644
index 0000000..e6923fb
@@ -0,0 +1,28 @@
+/*
+ * Architecture specific mm hooks
+ *
+ * Copyright (C) 2015, IBM Corporation
+ * Author: Laurent Dufour <[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __ASM_MM_ARCH_HOOKS_H
+#define __ASM_MM_ARCH_HOOKS_H
+
+static inline void arch_remap(struct mm_struct *mm,
+			      unsigned long old_start, unsigned long old_end,
+			      unsigned long new_start, unsigned long new_end)
+{
+	/*
+	 * mremap() doesn't allow moving multiple vmas so we can limit the
+	 * check to old_start == vdso_base.
+	 */
+	if ((void *)old_start == mm->context.vdso)
+		mm->context.vdso = (void *)new_start;
+}
+#define arch_remap arch_remap
+
+#endif /* __ASM_MM_ARCH_HOOKS_H */

arch/arm64/include/asm/mmu_context.h +17 -1

index 2416578..9fe0773 100644
@@ -24,7 +24,6 @@
 
 #include <asm/cacheflush.h>
 #include <asm/proc-fns.h>
-#include <asm-generic/mm_hooks.h>
 #include <asm/cputype.h>
 #include <asm/pgtable.h>

@@ -147,4 +146,26 @@ switch_mm(struct mm_struct *prev, struct mm_struct *next,
 #define deactivate_mm(tsk,mm)	do { } while (0)
 #define activate_mm(prev,next)	switch_mm(prev, next, NULL)
 
+static inline void arch_dup_mmap(struct mm_struct *oldmm,
+				      struct mm_struct *mm)
+{
+}
+
+static inline void arch_exit_mmap(struct mm_struct *mm)
+{
+}
+
+static inline void arch_unmap(struct mm_struct *mm,
+			      struct vm_area_struct *vma,
+			      unsigned long start, unsigned long end)
+{
+	if ((void *)start <= mm->context.vdso && mm->context.vdso < (void *)end)
+		mm->context.vdso = NULL;
+}
+

Quoted 8 lines

arch/arm64/include/asm/mmu_context.h switch_mm(struct mm_struct *prev, struct mm_struct *next, · line 169
Quoted 4 lines
arch/arm64/include/asm/mmu_context.h +4 -0
+static inline void arch_bprm_mm_init(struct mm_struct *mm,
+				     struct vm_area_struct *vma)
+{
+}
This is virtually identical to the PowerPC implementation, afaict. Any chance we could move this to core code and define some generic vdso accessors for the mm?

I think the same criticism applies to the VDSO code itself, and I'm not sure how easy it is to provide common VDSO remap/unmap without common VDSO code. I guess I'll do some investigating when I have then chance.

Thanks,
Christopher Covington

Signature · 3 lines

Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Christopher Covington

author

2016-04-28 15:18 UTC #3 lore raw

VDSO unmap and remap support for additional architectures

In reply to Will Deacon

Please take a look at the following prototype of sharing the PowerPC VDSO unmap and remap code with other architectures. I've only hooked up arm64 to begin with. If folks think this is a reasonable approach I can work on 32 bit ARM as well. Not hearing back from an earlier request for guidance [1], I simply dove in and started hacking. Laurent's test case [2][3] is a compelling illustration of whether VDSO remap works or not on a given architecture.

1. https://lkml.org/lkml/2016/3/2/225
2. https://lists.openvz.org/pipermail/criu/2015-March/019161.html
3. http://lists.openvz.org/pipermail/criu/attachments/20150318/f02ed9ea/attachment.bin

Thanks,
Christopher Covington

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Christopher Covington

author

2016-04-28 15:18 UTC #4 lore raw

RFC 1/5 powerpc: Rename context.vdso_base to context.vdso

In order to share remap and unmap support for the VDSO with other architectures without duplicating the code, we need a common name and type for the address of the VDSO. An informal survey of the architectures indicates unsigned long vdso is popular. Change the variable name in powerpc from mm->context.vdso_base to simply mm->context.vdso.

Signed-off-by Christopher Covington <[email protected]>

---
 arch/powerpc/include/asm/book3s/32/mmu-hash.h |  2 +-
 arch/powerpc/include/asm/book3s/64/mmu-hash.h |  2 +-
 arch/powerpc/include/asm/mm-arch-hooks.h      |  6 +++---
 arch/powerpc/include/asm/mmu-40x.h            |  2 +-
 arch/powerpc/include/asm/mmu-44x.h            |  2 +-
 arch/powerpc/include/asm/mmu-8xx.h            |  2 +-
 arch/powerpc/include/asm/mmu-book3e.h         |  2 +-
 arch/powerpc/include/asm/mmu_context.h        |  4 ++--
 arch/powerpc/include/asm/vdso.h               |  2 +-
 arch/powerpc/include/uapi/asm/elf.h           |  2 +-
 arch/powerpc/kernel/signal_32.c               |  8 ++++----
 arch/powerpc/kernel/signal_64.c               |  4 ++--
 arch/powerpc/kernel/vdso.c                    |  8 ++++----
 arch/powerpc/perf/callchain.c                 | 12 ++++++------
 14 files changed, 29 insertions(+), 29 deletions(-)

arch/powerpc/include/asm/book3s/32/mmu-hash.h +1 -1

index 16f513e..9d8de53 100644
@@ -79,7 +79,7 @@ struct hash_pte {
 
 typedef struct {
 	unsigned long id;
-	unsigned long vdso_base;
+	unsigned long vdso;
 } mm_context_t;
 
 #endif /* !__ASSEMBLY__ */

arch/powerpc/include/asm/book3s/64/mmu-hash.h +1 -1

index 0cea480..99df600 100644
@@ -525,7 +525,7 @@ typedef struct {
 #else
 	u16 sllp;		/* SLB page size encoding */
 #endif
-	unsigned long vdso_base;
+	unsigned long vdso;
 #ifdef CONFIG_PPC_SUBPAGE_PROT
 	struct subpage_prot_table spt;
 #endif /* CONFIG_PPC_SUBPAGE_PROT */

arch/powerpc/include/asm/mm-arch-hooks.h +3 -3

index f2a2da8..ea6da89 100644
@@ -18,10 +18,10 @@ static inline void arch_remap(struct mm_struct *mm,
 {
 	/*
 	 * mremap() doesn't allow moving multiple vmas so we can limit the
-	 * check to old_start == vdso_base.
+	 * check to old_start == vdso.
 	 */
-	if (old_start == mm->context.vdso_base)
-		mm->context.vdso_base = new_start;
+	if (old_start == mm->context.vdso)
+		mm->context.vdso = new_start;
 }
 #define arch_remap arch_remap

arch/powerpc/include/asm/mmu-40x.h +1 -1

index 3491686..e8e57b7 100644
@@ -56,7 +56,7 @@
 typedef struct {
 	unsigned int	id;
 	unsigned int	active;
-	unsigned long	vdso_base;
+	unsigned long	vdso;
 } mm_context_t;
 
 #endif /* !__ASSEMBLY__ */

arch/powerpc/include/asm/mmu-44x.h +1 -1

index bf52d70..471891c 100644
@@ -107,7 +107,7 @@ extern unsigned int tlb_44x_index;
 typedef struct {
 	unsigned int	id;
 	unsigned int	active;
-	unsigned long	vdso_base;
+	unsigned long	vdso;
 } mm_context_t;
 
 #endif /* !__ASSEMBLY__ */

arch/powerpc/include/asm/mmu-8xx.h +1 -1

index 0a566f1..9d1f160 100644
@@ -167,7 +167,7 @@
 typedef struct {
 	unsigned int id;
 	unsigned int active;
-	unsigned long vdso_base;
+	unsigned long vdso;
 } mm_context_t;
 #endif /* !__ASSEMBLY__ */

arch/powerpc/include/asm/mmu-book3e.h +1 -1

index cd4f04a..0cf1d11 100644
@@ -228,7 +228,7 @@ extern unsigned int tlbcam_index;
 typedef struct {
 	unsigned int	id;
 	unsigned int	active;
-	unsigned long	vdso_base;
+	unsigned long	vdso;
 #ifdef CONFIG_PPC_MM_SLICES
 	u64 low_slices_psize;   /* SLB page size encodings */
 	u64 high_slices_psize;  /* 4 bits per slice for now */

arch/powerpc/include/asm/mmu_context.h +2 -2

index 4eaab40..508b842 100644
@@ -139,8 +139,8 @@ static inline void arch_unmap(struct mm_struct *mm,
 			      struct vm_area_struct *vma,
 			      unsigned long start, unsigned long end)
 {
-	if (start <= mm->context.vdso_base && mm->context.vdso_base < end)
-		mm->context.vdso_base = 0;
+	if (start <= mm->context.vdso && mm->context.vdso < end)
+		mm->context.vdso = 0;
 }
 
 static inline void arch_bprm_mm_init(struct mm_struct *mm,

arch/powerpc/include/asm/vdso.h +1 -1

index c53f5f6..fc90971 100644
@@ -17,7 +17,7 @@
 
 #ifndef __ASSEMBLY__
 
-/* Offsets relative to thread->vdso_base */
+/* Offsets relative to mm->context.vdso */
 extern unsigned long vdso64_rt_sigtramp;
 extern unsigned long vdso32_sigtramp;
 extern unsigned long vdso32_rt_sigtramp;

arch/powerpc/include/uapi/asm/elf.h +1 -1

index c2d21d1..6cf0bbf 100644
@@ -177,7 +177,7 @@ do {									\
 	NEW_AUX_ENT(AT_DCACHEBSIZE, dcache_bsize);			\
 	NEW_AUX_ENT(AT_ICACHEBSIZE, icache_bsize);			\
 	NEW_AUX_ENT(AT_UCACHEBSIZE, ucache_bsize);			\
-	VDSO_AUX_ENT(AT_SYSINFO_EHDR, current->mm->context.vdso_base);	\
+	VDSO_AUX_ENT(AT_SYSINFO_EHDR, current->mm->context.vdso);	\
 } while (0)
 
 /* PowerPC64 relocations defined by the ABIs */

arch/powerpc/kernel/signal_32.c +4 -4

index b6aa378..39c39d72 100644
@@ -1000,9 +1000,9 @@ int handle_rt_signal32(struct ksignal *ksig, sigset_t *oldset,
 	/* Save user registers on the stack */
 	frame = &rt_sf->uc.uc_mcontext;
 	addr = frame;
-	if (vdso32_rt_sigtramp && current->mm->context.vdso_base) {
+	if (vdso32_rt_sigtramp && current->mm->context.vdso) {
 		sigret = 0;
-		tramp = current->mm->context.vdso_base + vdso32_rt_sigtramp;
+		tramp = current->mm->context.vdso + vdso32_rt_sigtramp;
 	} else {
 		sigret = __NR_rt_sigreturn;
 		tramp = (unsigned long) frame->tramp;

@@ -1425,9 +1425,9 @@ int handle_signal32(struct ksignal *ksig, sigset_t *oldset, struct pt_regs *regs
 	    || __put_user(ksig->sig, &sc->signal))
 		goto badframe;
 
-	if (vdso32_sigtramp && current->mm->context.vdso_base) {
+	if (vdso32_sigtramp && current->mm->context.vdso) {
 		sigret = 0;
-		tramp = current->mm->context.vdso_base + vdso32_sigtramp;
+		tramp = current->mm->context.vdso + vdso32_sigtramp;
 	} else {
 		sigret = __NR_sigreturn;
 		tramp = (unsigned long) frame->mctx.tramp;

arch/powerpc/kernel/signal_64.c +2 -2

index 2552079..4cb437f 100644
@@ -751,8 +751,8 @@ int handle_rt_signal64(struct ksignal *ksig, sigset_t *set, struct pt_regs *regs
 	current->thread.fp_state.fpscr = 0;
 
 	/* Set up to return from userspace. */
-	if (vdso64_rt_sigtramp && current->mm->context.vdso_base) {
-		regs->link = current->mm->context.vdso_base + vdso64_rt_sigtramp;
+	if (vdso64_rt_sigtramp && current->mm->context.vdso) {
+		regs->link = current->mm->context.vdso + vdso64_rt_sigtramp;
 	} else {
 		err |= setup_trampoline(__NR_rt_sigreturn, &frame->tramp[0]);
 		if (err)

arch/powerpc/kernel/vdso.c +4 -4

index def1b8b..e6e5f68 100644
@@ -179,7 +179,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
 	vdso_base = VDSO32_MBASE;
 #endif
 
-	current->mm->context.vdso_base = 0;
+	current->mm->context.vdso = 0;
 
 	/* vDSO has a problem and was disabled, just don't "enable" it for the
 	 * process

@@ -213,7 +213,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
 	 * install_special_mapping or the perf counter mmap tracking code
 	 * will fail to recognise it as a vDSO (since arch_vma_name fails).
 	 */
-	current->mm->context.vdso_base = vdso_base;
+	current->mm->context.vdso = vdso_base;
 
 	/*
 	 * our vma flags don't have VM_WRITE so by default, the process isn't

@@ -230,7 +230,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
 				     VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
 				     vdso_pagelist);
 	if (rc) {
-		current->mm->context.vdso_base = 0;
+		current->mm->context.vdso = 0;
 		goto fail_mmapsem;
 	}

@@ -244,7 +244,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
 
 const char *arch_vma_name(struct vm_area_struct *vma)
 {
-	if (vma->vm_mm && vma->vm_start == vma->vm_mm->context.vdso_base)
+	if (vma->vm_mm && vma->vm_start == vma->vm_mm->context.vdso)
 		return "[vdso]";
 	return NULL;
 }

arch/powerpc/perf/callchain.c +6 -6

index e04a675..04fc505 100644
@@ -209,8 +209,8 @@ static int is_sigreturn_64_address(unsigned long nip, unsigned long fp)
 {
 	if (nip == fp + offsetof(struct signal_frame_64, tramp))
 		return 1;
-	if (vdso64_rt_sigtramp && current->mm->context.vdso_base &&
-	    nip == current->mm->context.vdso_base + vdso64_rt_sigtramp)
+	if (vdso64_rt_sigtramp && current->mm->context.vdso &&
+	    nip == current->mm->context.vdso + vdso64_rt_sigtramp)
 		return 1;
 	return 0;
 }

@@ -368,8 +368,8 @@ static int is_sigreturn_32_address(unsigned int nip, unsigned int fp)
 {
 	if (nip == fp + offsetof(struct signal_frame_32, mctx.mc_pad))
 		return 1;
-	if (vdso32_sigtramp && current->mm->context.vdso_base &&
-	    nip == current->mm->context.vdso_base + vdso32_sigtramp)
+	if (vdso32_sigtramp && current->mm->context.vdso &&
+	    nip == current->mm->context.vdso + vdso32_sigtramp)
 		return 1;
 	return 0;
 }

@@ -379,8 +379,8 @@ static int is_rt_sigreturn_32_address(unsigned int nip, unsigned int fp)
 	if (nip == fp + offsetof(struct rt_signal_frame_32,
 				 uc.uc_mcontext.mc_pad))
 		return 1;
-	if (vdso32_rt_sigtramp && current->mm->context.vdso_base &&
-	    nip == current->mm->context.vdso_base + vdso32_rt_sigtramp)
+	if (vdso32_rt_sigtramp && current->mm->context.vdso &&
+	    nip == current->mm->context.vdso + vdso32_rt_sigtramp)
 		return 1;
 	return 0;
 }

Signature · 9 lines

Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Balbir Singh

2016-05-02 01:05 UTC #5 lore raw

Re: [RFC 1/5] powerpc: Rename context.vdso_base to context.vdso

Quoted 6 lines · Christopher Covington

In order to share remap and unmap support for the VDSO with other architectures without duplicating the code, we need a common name and type for the address of the VDSO. An informal survey of the architectures indicates unsigned long vdso is popular. Change the variable name in powerpc from mm->context.vdso_base to simply mm->context.vdso.

Could you please provide additional details on why the remap/unmap operations are required?
This patch does rename, but should it abstract via a function acesss to vmap field using arch_* operations? Not sure

Balbir Singh

Christopher Covington

author

2016-05-04 21:21 UTC #6 lore raw

Re: [RFC 1/5] powerpc: Rename context.vdso_base to context.vdso

Hi Balbir,

Quoted 8 lines · Balbir Singh

Quoted 5 lines · Christopher Covington
In order to share remap and unmap support for the VDSO with other architectures without duplicating the code, we need a common name and type for the address of the VDSO. An informal survey of the architectures indicates unsigned long vdso is popular. Change the variable name in powerpc from mm->context.vdso_base to simply mm->context.vdso.
Could you please provide additional details on why the remap/unmap operations are required?

The goal is to make checkpointing and restoring processes work on several different architectures and ABIs, in the face of Address Space Layout Randomization (ASLR) and other factors that might change the VDSO virtual address from one exec() to the next.

Here's the patch adding PowerPC support:

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=83d3f0e90c6c8f833e3da91917c243a916fda69e

Quoted 2 lines

This patch does rename, but should it abstract via a function acesss to vmap field using arch_* operations? Not sure

I'm sorry, but I don't understand this question. Are you saying ARM, Power etc. need VDSO unmap and remap log that behave differently? So far I've found the differences to be stylistic rather than really affecting generated code behavior.

Thanks,
Christopher Covington

Signature · 3 lines

Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Christopher Covington

author

2016-04-28 15:18 UTC #7 lore raw

RFC 2/5 mm/powerpc: Make VDSO unmap generic

In reply to Christopher Covington

In order to support unmapping the VDSO on additional architectures, move the unmap code out from arch/powerpc. Architectures that wish to use the generic logic must have an unsigned long vdso in mm->context and can opt in by selecting CONFIG_ARCH_WANT_VDSO_MAP. This allows PowerPC to go back to using the generic MM hooks, instead of carrying its own.

Signed-off-by Christopher Covington <[email protected]>

---
 arch/powerpc/Kconfig                   |  1 +
 arch/powerpc/include/asm/mmu_context.h | 35 +---------------------------------
 include/asm-generic/mm_hooks.h         |  4 ++++
 3 files changed, 6 insertions(+), 34 deletions(-)

arch/powerpc/Kconfig +1 -0

index 7cd32c0..f74320e 100644
@@ -160,6 +160,7 @@ config PPC
 	select HAVE_ARCH_SECCOMP_FILTER
 	select ARCH_HAS_UBSAN_SANITIZE_ALL
 	select ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT
+	select ARCH_WANT_VDSO_MAP
 
 config GENERIC_CSUM
 	def_bool CPU_LITTLE_ENDIAN

arch/powerpc/include/asm/mmu_context.h +1 ~~-34~~

index 508b842..3e51842 100644
@@ -8,6 +8,7 @@
 #include <linux/spinlock.h>
 #include <asm/mmu.h>	
 #include <asm/cputable.h>
+#include <asm-generic/mm_hooks.h>
 #include <asm/cputhreads.h>
 
 /*

@@ -126,39 +127,5 @@ static inline void enter_lazy_tlb(struct mm_struct *mm,
 #endif
 }
 
-static inline void arch_dup_mmap(struct mm_struct *oldmm,
-				 struct mm_struct *mm)
-{
-}
-
-static inline void arch_exit_mmap(struct mm_struct *mm)
-{
-}
-
-static inline void arch_unmap(struct mm_struct *mm,
-			      struct vm_area_struct *vma,
-			      unsigned long start, unsigned long end)
-{
-	if (start <= mm->context.vdso && mm->context.vdso < end)
-		mm->context.vdso = 0;
-}
-
-static inline void arch_bprm_mm_init(struct mm_struct *mm,
-				     struct vm_area_struct *vma)
-{
-}
-
-static inline bool arch_vma_access_permitted(struct vm_area_struct *vma,
-		bool write, bool execute, bool foreign)
-{
-	/* by default, allow everything */
-	return true;
-}
-
-static inline bool arch_pte_access_permitted(pte_t pte, bool write)
-{
-	/* by default, allow everything */
-	return true;
-}
 #endif /* __KERNEL__ */
 #endif /* __ASM_POWERPC_MMU_CONTEXT_H */

include/asm-generic/mm_hooks.h +4 -0

index cc5d9a14..6645116 100644
@@ -19,6 +19,10 @@ static inline void arch_unmap(struct mm_struct *mm,
 			struct vm_area_struct *vma,
 			unsigned long start, unsigned long end)
 {
+#ifdef CONFIG_ARCH_WANT_VDSO_MAP
+	if (start <= mm->context.vdso && mm->context.vdso < end)
+		mm->context.vdso = 0;
+#endif  /* CONFIG_ARCH_WANT_VDSO_MAP */
 }
 
 static inline void arch_bprm_mm_init(struct mm_struct *mm,

Signature · 9 lines

Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Christopher Covington

author

2016-04-28 15:18 UTC #8 lore raw

RFC 3/5 mm/powerpc: Make VDSO remap generic

In reply to Christopher Covington

In order to support remapping the VDSO on additional architectures without duplicating code, move the remap code out from arch/powerpc. Architectures that wish to use the generic logic must have an unsigned long vdso in mm->context and can opt in by selecting CONFIG_ARCH_WANT_VDSO_MAP. This allows PowerPC to use mm-arch-hooks.h from include/asm-generic.

Signed-off-by Christopher Covington <[email protected]>

---
 arch/powerpc/include/asm/Kbuild          |  1 +
 arch/powerpc/include/asm/mm-arch-hooks.h | 28 ----------------------------
 mm/mremap.c                              | 10 ++++++++--
 3 files changed, 9 insertions(+), 30 deletions(-)
 delete mode 100644 arch/powerpc/include/asm/mm-arch-hooks.h

arch/powerpc/include/asm/Kbuild +1 -0

index ab9f4e0..9dbb372 100644
@@ -7,3 +7,4 @@ generic-y += mcs_spinlock.h
 generic-y += preempt.h
 generic-y += rwsem.h
 generic-y += vtime.h
+generic-y += mm-arch-hooks.h

arch/powerpc/include/asm/mm-arch-hooks.h deleted +0 ~~-28~~

deleted file mode 100644
index ea6da89..0000000
@@ -1,28 +0,0 @@
-/*
- * Architecture specific mm hooks
- *
- * Copyright (C) 2015, IBM Corporation
- * Author: Laurent Dufour <[email protected]>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#ifndef _ASM_POWERPC_MM_ARCH_HOOKS_H
-#define _ASM_POWERPC_MM_ARCH_HOOKS_H
-
-static inline void arch_remap(struct mm_struct *mm,
-			      unsigned long old_start, unsigned long old_end,
-			      unsigned long new_start, unsigned long new_end)
-{
-	/*
-	 * mremap() doesn't allow moving multiple vmas so we can limit the
-	 * check to old_start == vdso.
-	 */
-	if (old_start == mm->context.vdso)
-		mm->context.vdso = new_start;
-}
-#define arch_remap arch_remap
-
-#endif /* _ASM_POWERPC_MM_ARCH_HOOKS_H */

mm/mremap.c +8 -2

index 3fa0a467..59032b7 100644
@@ -293,8 +293,14 @@ static unsigned long move_vma(struct vm_area_struct *vma,
 		old_addr = new_addr;
 		new_addr = err;
 	} else {
-		arch_remap(mm, old_addr, old_addr + old_len,
-			   new_addr, new_addr + new_len);
+#ifdef CONFIG_ARCH_WANT_VDSO_MAP
+		/*
+		 * mremap() doesn't allow moving multiple vmas so we can limit the
+		 * check to old_addr == vdso.
+		 */
+		if (old_addr == mm->context.vdso)
+			mm->context.vdso = new_addr;
+#endif  /* CONFIG_ARCH_WANT_VDSO_MAP */
 	}
 
 	/* Conceal VM_ACCOUNT so old reservation is not undone */

Signature · 9 lines

Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Christopher Covington

author

2016-04-28 15:18 UTC #9 lore raw

RFC 4/5 arm64: Use unsigned long for vdso

In reply to Christopher Covington

In order to get AArch64 remap and unmap support for the VDSO, like PowerPC and x86 have, without duplicating the code, we need a common name and type for the address of the VDSO. An informal survey of the architectures indicates unsigned long vdso is popular. Change the type in arm64 to be unsigned long, which has the added benefit of dropping a few typecasts.

Signed-off-by Christopher Covington <[email protected]>

---
 arch/arm64/include/asm/mmu.h | 2 +-
 arch/arm64/kernel/vdso.c     | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

arch/arm64/include/asm/mmu.h +1 -1

index 990124a..a67352f 100644
@@ -18,7 +18,7 @@
 
 typedef struct {
 	atomic64_t	id;
-	void		*vdso;
+	unsigned long	vdso;
 } mm_context_t;
 
 /*

arch/arm64/kernel/vdso.c +3 -3

index 97bc68f..e742b1d 100644
@@ -96,7 +96,7 @@ int aarch32_setup_vectors_page(struct linux_binprm *bprm, int uses_interp)
 	void *ret;
 
 	down_write(&mm->mmap_sem);
-	current->mm->context.vdso = (void *)addr;
+	current->mm->context.vdso = addr;
 
 	/* Map vectors page at the high address. */
 	ret = _install_special_mapping(mm, addr, PAGE_SIZE,

@@ -176,7 +176,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm,
 		goto up_fail;
 
 	vdso_base += PAGE_SIZE;
-	mm->context.vdso = (void *)vdso_base;
+	mm->context.vdso = vdso_base;
 	ret = _install_special_mapping(mm, vdso_base, vdso_text_len,
 				       VM_READ|VM_EXEC|
 				       VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,

@@ -189,7 +189,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm,
 	return 0;
 
 up_fail:
-	mm->context.vdso = NULL;
+	mm->context.vdso = 0;
 	up_write(&mm->mmap_sem);
 	return PTR_ERR(ret);
 }

Signature · 9 lines

Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Christopher Covington

author

2016-04-28 15:18 UTC #10 lore raw

RFC 5/5 arm64: Gain VDSO unmap and remap powers

In reply to Christopher Covington

Checkpoint/Restore In Userspace (CRIU) must be able to remap and unmap the Virtual Dynamic Shared Object (VDSO) to be able to handle the changing addresses that result from address space layout randomization. Now that the support for this originally written for PowerPC has been moved to a generic location and arm64 has adopted unsigned long for the type of mm->context.vdso, simply opt-in to VDSO unmap and remap support.

Signed-off-by Christopher Covington <[email protected]>

---
 arch/arm64/Kconfig | 1 +
 1 file changed, 1 insertion(+)

arch/arm64/Kconfig +1 -0

index 4f43622..cbdce39 100644
@@ -14,6 +14,7 @@ config ARM64
 	select ARCH_WANT_OPTIONAL_GPIOLIB
 	select ARCH_WANT_COMPAT_IPC_PARSE_VERSION
 	select ARCH_WANT_FRAME_POINTERS
+	select ARCH_WANT_VDSO_MAP
 	select ARCH_HAS_UBSAN_SANITIZE_ALL
 	select ARM_AMBA
 	select ARM_ARCH_TIMER

Signature · 9 lines

Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Andy Lutomirski

2016-04-28 18:53 UTC #11 lore raw

Re: VDSO unmap and remap support for additional architectures

In reply to Christopher Covington

Quoted 7 lines · Christopher Covington

Please take a look at the following prototype of sharing the PowerPC VDSO unmap and remap code with other architectures. I've only hooked up arm64 to begin with. If folks think this is a reasonable approach I can work on 32 bit ARM as well. Not hearing back from an earlier request for guidance [1], I simply dove in and started hacking. Laurent's test case [2][3] is a compelling illustration of whether VDSO remap works or not on a given architecture.

I think there's a much nicer way:

https://lkml.kernel.org/r/[email protected]

Could arm64 and ppc use this approach? These arch_xyz hooks are gross.

Also, at some point, possibly quite soon, x86 will want a way for user code to ask the kernel to map a specific vdso variant at a specific address. Could we perhaps add a new pair of syscalls:

struct vdso_info {
    unsigned long space_needed_before;
    unsigned long space_needed_after;
    unsigned long alignment;
};

long vdso_get_info(unsigned int vdso_type, struct vdso_info *info);

long vdso_remap(unsigned int vdso_type, unsigned long addr, unsigned int flags);

#define VDSO_X86_I386 0
#define VDSO_X86_64 1
#define VDSO_X86_X32 2
// etc.

vdso_remap will map the vdso of the chosen type such at AT_SYSINFO_EHDR lines up with addr. It will use up to space_needed_before bytes before that address and space_needed_after after than address. It will also unmap the old vdso (or maybe only do that if some flag is set).

On x86, mremap is *not* sufficient for everything that's needed, because some programs will need to change the vdso type.

--Andy

Christopher Covington

author

2016-04-29 13:22 UTC #12 lore raw

Re: VDSO unmap and remap support for additional architectures

Hi Andy,

Quoted 9 lines · Andy Lutomirski

Quoted 7 lines · Christopher Covington
Please take a look at the following prototype of sharing the PowerPC VDSO unmap and remap code with other architectures. I've only hooked up arm64 to begin with. If folks think this is a reasonable approach I can work on 32 bit ARM as well. Not hearing back from an earlier request for guidance [1], I simply dove in and started hacking. Laurent's test case [2][3] is a compelling illustration of whether VDSO remap works or not on a given architecture.

Quoted 5 lines

I think there's a much nicer way:
https://lkml.kernel.org/r/[email protected]
Could arm64 and ppc use this approach? These arch_xyz hooks are gross.

Thanks for the pointer. Any thoughts on how to keep essentially identical definitions of vdso_mremap from proliferating into every architecture and variant?

Quoted 19 lines

Also, at some point, possibly quite soon, x86 will want a way for user code to ask the kernel to map a specific vdso variant at a specific address. Could we perhaps add a new pair of syscalls:
struct vdso_info {
    unsigned long space_needed_before;
    unsigned long space_needed_after;
    unsigned long alignment;
};
long vdso_get_info(unsigned int vdso_type, struct vdso_info *info);
long vdso_remap(unsigned int vdso_type, unsigned long addr, unsigned int flags);
#define VDSO_X86_I386 0
#define VDSO_X86_64 1
#define VDSO_X86_X32 2
// etc.

Quoted 8 lines

vdso_remap will map the vdso of the chosen type such at AT_SYSINFO_EHDR lines up with addr. It will use up to space_needed_before bytes before that address and space_needed_after after than address. It will also unmap the old vdso (or maybe only do that if some flag is set).
On x86, mremap is *not* sufficient for everything that's needed, because some programs will need to change the vdso type.

I don't I understand. Why can't people just exec() the ELF type that corresponds to the VDSO they want?

Thanks,
Cov

Signature · 9 lines

Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Dmitry Safonov

2016-04-29 13:55 UTC #13 lore raw

Re: VDSO unmap and remap support for additional architectures

Quoted 26 lines · Christopher Covington

Quoted 25 lines · Andy Lutomirski
Also, at some point, possibly quite soon, x86 will want a way for user code to ask the kernel to map a specific vdso variant at a specific address. Could we perhaps add a new pair of syscalls:
struct vdso_info {
     unsigned long space_needed_before;
     unsigned long space_needed_after;
     unsigned long alignment;
};
long vdso_get_info(unsigned int vdso_type, struct vdso_info *info);
long vdso_remap(unsigned int vdso_type, unsigned long addr, unsigned int flags);
#define VDSO_X86_I386 0
#define VDSO_X86_64 1
#define VDSO_X86_X32 2
// etc.
vdso_remap will map the vdso of the chosen type such at AT_SYSINFO_EHDR lines up with addr. It will use up to space_needed_before bytes before that address and space_needed_after after than address. It will also unmap the old vdso (or maybe only do that if some flag is set).

Quoted 4 lines

Quoted 2 lines
On x86, mremap is *not* sufficient for everything that's needed, because some programs will need to change the vdso type.
I don't I understand. Why can't people just exec() the ELF type that corresponds to the VDSO they want?

I may say about my needs in it: to not lose all the existing information in application.
Imagine you're restoring a container with 64-bit and 32-bit applications (in compatible mode). So you need somehow switch vdso type in restorer for a 32-bit application. Yes, you may exec() and then - all already restored application properties will got lost. You will need to transpher information about mappings, make protocol between restorer binary and main criu application, finally you'll end up with some really much more difficult architecture than it is now. And it'll be slower.

Also it's pretty logical: if one can switch between modes, why can't he change vdso mapping to mode he got to? (note: if the work about removing thread compatible flags will be done (on x86), there will not even be such a thing, as application mode - just difference on which syscalls it
uses: compatible or native).

Thanks,
Dmitry Safonov

Christopher Covington

author

2016-05-03 21:37 UTC #14 lore raw

Re: VDSO unmap and remap support for additional architectures

Quoted 33 lines · Dmitry Safonov

Quoted 27 lines · Christopher Covington
Quoted 26 lines · Andy Lutomirski
Also, at some point, possibly quite soon, x86 will want a way for user code to ask the kernel to map a specific vdso variant at a specific address. Could we perhaps add a new pair of syscalls:
struct vdso_info {
     unsigned long space_needed_before;
     unsigned long space_needed_after;
     unsigned long alignment;
};
long vdso_get_info(unsigned int vdso_type, struct vdso_info *info);
long vdso_remap(unsigned int vdso_type, unsigned long addr, unsigned int flags);
#define VDSO_X86_I386 0
#define VDSO_X86_64 1
#define VDSO_X86_X32 2
// etc.
vdso_remap will map the vdso of the chosen type such at AT_SYSINFO_EHDR lines up with addr. It will use up to space_needed_before bytes before that address and space_needed_after after than address. It will also unmap the old vdso (or maybe only do that if some flag is set).
Quoted 4 lines
Quoted 2 lines
On x86, mremap is *not* sufficient for everything that's needed, because some programs will need to change the vdso type.
I don't I understand. Why can't people just exec() the ELF type that corresponds to the VDSO they want?

Quoted 11 lines

I may say about my needs in it: to not lose all the existing information in application.
Imagine you're restoring a container with 64-bit and 32-bit applications (in compatible mode). So you need somehow switch vdso type in restorer for a 32-bit application. Yes, you may exec() and then - all already restored application properties will got lost. You will need to transpher information about mappings, make protocol between restorer binary and main criu application, finally you'll end up with some really much more difficult architecture than it is now. And it'll be slower.

Perhaps a more modest exec based strategy would be for x86_64 criu to handle all of the x86_64 restores as usual but exec i386 and/or x32 criu service daemons and use them for restoring applications needing those ABIs.

Regards,
Christopher Covington

Signature · 9 lines

Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>