Tracking user space vDSO remaping

Some architecture would like to be triggered when a memory area is moved through the mremap system call.

This patch is introducing a new arch_remap mm hook which is placed in the path of mremap, and is called before the old area is unmapped (and the arch_unmap hook is called).

To no break the build, this patch adds the empty hook definition to the architectures that were not using the generic hook's definition.

Some architecture would like to be triggered when a memory area is moved through the mremap system call.

This patch is introducing a new arch_remap mm hook which is placed in the path of mremap, and is called before the old area is unmapped (and the arch_unmap hook is called).

To no break the build, this patch adds the empty hook definition to the architectures that were not using the generic hook's definition.

Signed-off-by Laurent Dufour <[email protected]>

---
 arch/s390/include/asm/mmu_context.h      | 6 ++++++
 arch/um/include/asm/mmu_context.h        | 5 +++++
 arch/unicore32/include/asm/mmu_context.h | 6 ++++++
 arch/x86/include/asm/mmu_context.h       | 6 ++++++
 include/asm-generic/mm_hooks.h           | 6 ++++++
 mm/mremap.c                              | 9 +++++++--
 6 files changed, 36 insertions(+), 2 deletions(-)

arch/s390/include/asm/mmu_context.h +6 -0

index 8fb3802f8fad..ddd861a490ba 100644
@@ -131,4 +131,10 @@ static inline void arch_bprm_mm_init(struct mm_struct *mm,
 {
 }
 
+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)
+{
+}
+
 #endif /* __S390_MMU_CONTEXT_H */

arch/um/include/asm/mmu_context.h +5 -0

index 941527e507f7..f499b017c1f9 100644
@@ -27,6 +27,11 @@ static inline void arch_bprm_mm_init(struct mm_struct *mm,
 				     struct vm_area_struct *vma)
 {
 }
+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)
+{
+}
 /*
  * end asm-generic/mm_hooks.h functions
  */

arch/unicore32/include/asm/mmu_context.h +6 -0

index 1cb5220afaf9..39a0a553172e 100644
@@ -97,4 +97,10 @@ static inline void arch_bprm_mm_init(struct mm_struct *mm,
 {
 }
 
+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)
+{
+}
+
 #endif

arch/x86/include/asm/mmu_context.h +0 -0

index 883f6b933fa4..75cb71f4be1e 100644

Quoted 71 lines · Laurent Dufour

Some architecture would like to be triggered when a memory area is moved through the mremap system call.

This patch is introducing a new arch_remap mm hook which is placed in the path of mremap, and is called before the old area is unmapped (and the arch_unmap hook is called).

To no break the build, this patch adds the empty hook definition to the architectures that were not using the generic hook's definition.

Signed-off-by Laurent Dufour <[email protected]>

---
 arch/s390/include/asm/mmu_context.h      | 6 ++++++
 arch/um/include/asm/mmu_context.h        | 5 +++++
 arch/unicore32/include/asm/mmu_context.h | 6 ++++++
 arch/x86/include/asm/mmu_context.h       | 6 ++++++
 include/asm-generic/mm_hooks.h           | 6 ++++++
 mm/mremap.c                              | 9 +++++++--
 6 files changed, 36 insertions(+), 2 deletions(-)

arch/s390/include/asm/mmu_context.h +6 -0

index 8fb3802f8fad..ddd861a490ba 100644
@@ -131,4 +131,10 @@ static inline void arch_bprm_mm_init(struct mm_struct *mm,
 {
 }
 
+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)
+{
+}
+
 #endif /* __S390_MMU_CONTEXT_H */

arch/um/include/asm/mmu_context.h +5 -0

index 941527e507f7..f499b017c1f9 100644
@@ -27,6 +27,11 @@ static inline void arch_bprm_mm_init(struct mm_struct *mm,
 				     struct vm_area_struct *vma)
 {
 }
+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)
+{
+}
 /*
  * end asm-generic/mm_hooks.h functions
  */

arch/unicore32/include/asm/mmu_context.h +6 -0

index 1cb5220afaf9..39a0a553172e 100644
@@ -97,4 +97,10 @@ static inline void arch_bprm_mm_init(struct mm_struct *mm,
 {
 }
 
+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)
+{
+}
+
 #endif

arch/x86/include/asm/mmu_context.h +0 -0

index 883f6b933fa4..75cb71f4be1e 100644

arch/x86/include/asm/mmu_context.h static inline void arch_unmap(struct mm_struct *mm, struct vm_area_struct *vma, · line 181

Quoted 10 lines

arch/x86/include/asm/mmu_context.h +6 -0

@@ -172,4 +172,10 @@ static inline void arch_unmap(struct mm_struct *mm, struct vm_area_struct *vma,
 		mpx_notify_unmap(mm, vma, start, end);
 }
 
+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)
+{
+}
+
 #endif /* _ASM_X86_MMU_CONTEXT_H */

So instead of spreading these empty prototypes around mmu_context.h files, why not add something like this to the PPC definition:

#define __HAVE_ARCH_REMAP

and define the empty prototype for everyone else? It's a bit like how the __HAVE_ARCH_PTEP_* namespace works.

That should shrink this patch considerably.

Some processes (CRIU) are moving the vDSO area using the mremap system call. As a consequence the kernel reference to the vDSO base address is no more valid and the signal return frame built once the vDSO has been moved is not pointing to the new sigreturn address.

This patch handles vDSO remapping and unmapping.

Signed-off-by Laurent Dufour <[email protected]>

---
 arch/powerpc/include/asm/mmu_context.h | 36 +++++++++++++++++++++++++++++++++-
 1 file changed, 35 insertions(+), 1 deletion(-)

arch/powerpc/include/asm/mmu_context.h +20 -1

index 73382eba02dc..be5dca3f7826 100644
@@ -8,7 +8,6 @@
 #include <linux/spinlock.h>
 #include <asm/mmu.h>	
 #include <asm/cputable.h>
-#include <asm-generic/mm_hooks.h>
 #include <asm/cputhreads.h>
 
 /*

@@ -109,5 +108,40 @@ 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_base && mm->context.vdso_base < end)
+		mm->context.vdso_base = 0;
+}
+
+static inline void arch_bprm_mm_init(struct mm_struct *mm,
+				     struct vm_area_struct *vma)
+{

Quoted 48 lines · Laurent Dufour

Some processes (CRIU) are moving the vDSO area using the mremap system call. As a consequence the kernel reference to the vDSO base address is no more valid and the signal return frame built once the vDSO has been moved is not pointing to the new sigreturn address.

This patch handles vDSO remapping and unmapping.

Signed-off-by Laurent Dufour <[email protected]>

---
 arch/powerpc/include/asm/mmu_context.h | 36 +++++++++++++++++++++++++++++++++-
 1 file changed, 35 insertions(+), 1 deletion(-)

arch/powerpc/include/asm/mmu_context.h +20 -1

index 73382eba02dc..be5dca3f7826 100644
@@ -8,7 +8,6 @@
 #include <linux/spinlock.h>
 #include <asm/mmu.h>	
 #include <asm/cputable.h>
-#include <asm-generic/mm_hooks.h>
 #include <asm/cputhreads.h>
 
 /*

@@ -109,5 +108,40 @@ 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_base && mm->context.vdso_base < end)
+		mm->context.vdso_base = 0;
+}
+
+static inline void arch_bprm_mm_init(struct mm_struct *mm,
+				     struct vm_area_struct *vma)
+{

arch/powerpc/include/asm/mmu_context.h static inline void enter_lazy_tlb(struct mm_struct *mm, · line 140

Quoted 10 lines

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

+}
+
+#define __HAVE_ARCH_REMAP
+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 don't allow moving multiple vma so we can limit the check
+	 * to old_start == vdso_base.

s/mremap don't allow moving multiple vma
mremap() doesn't allow moving multiple vmas

right?

Quoted 8 lines

arch/powerpc/include/asm/mmu_context.h +8 -0

+#define __HAVE_ARCH_REMAP
+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.

arch/powerpc/include/asm/mmu_context.h static inline void enter_lazy_tlb(struct mm_struct *mm, · line 144

Quoted 4 lines

arch/powerpc/include/asm/mmu_context.h +4 -0

+	 */
+	if (old_start == mm->context.vdso_base)
+		mm->context.vdso_base = new_start;
+}

mremap() doesn't allow moving multiple vmas, but it allows the movement of multi-page vmas and it also allows partial mremap()s, where it will split up a vma.

Quoted 8 lines · Ingo Molnar

Quoted 8 lines

arch/powerpc/include/asm/mmu_context.h +8 -0

+#define __HAVE_ARCH_REMAP
+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.

Quoted 8 lines

arch/powerpc/include/asm/mmu_context.h static inline void enter_lazy_tlb(struct mm_struct *mm, · line 144

Quoted 4 lines

arch/powerpc/include/asm/mmu_context.h +4 -0

+	 */
+	if (old_start == mm->context.vdso_base)
+		mm->context.vdso_base = new_start;
+}

mremap() doesn't allow moving multiple vmas, but it allows the movement of multi-page vmas and it also allows partial mremap()s, where it will split up a vma.

I.e. mremap() supports the shrinking (and growing) of vmas. In that case mremap() will unmap the end of the vma and will shrink the remaining vDSO vma.

Doesn't that result in a non-working vDSO that should zero out vdso_base?

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Quoted 23 lines · Ingo Molnar

Quoted 8 lines · Ingo Molnar

Quoted 8 lines

arch/powerpc/include/asm/mmu_context.h +8 -0

+#define __HAVE_ARCH_REMAP
+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.

Quoted 8 lines

arch/powerpc/include/asm/mmu_context.h static inline void enter_lazy_tlb(struct mm_struct *mm, · line 144

Quoted 4 lines

arch/powerpc/include/asm/mmu_context.h +4 -0

+	 */
+	if (old_start == mm->context.vdso_base)
+		mm->context.vdso_base = new_start;
+}

mremap() doesn't allow moving multiple vmas, but it allows the movement of multi-page vmas and it also allows partial mremap()s, where it will split up a vma.

I.e. mremap() supports the shrinking (and growing) of vmas. In that case mremap() will unmap the end of the vma and will shrink the remaining vDSO vma.

Quoted 2 lines

Doesn't that result in a non-working vDSO that should zero out vdso_base?

Right. Now we can't completely prevent the user from shooting itself in the foot I suppose, though there is a legit usage scenario which is to move the vDSO around which it would be nice to support. I think it's reasonable to put the onus on the user here to do the right thing.

Quoted 24 lines · Benjamin Herrenschmidt

Quoted 23 lines · Ingo Molnar

Quoted 8 lines · Ingo Molnar

Quoted 8 lines

arch/powerpc/include/asm/mmu_context.h +8 -0

+#define __HAVE_ARCH_REMAP
+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.

Quoted 8 lines

arch/powerpc/include/asm/mmu_context.h static inline void enter_lazy_tlb(struct mm_struct *mm, · line 144

Quoted 4 lines

arch/powerpc/include/asm/mmu_context.h +4 -0

+	 */
+	if (old_start == mm->context.vdso_base)
+		mm->context.vdso_base = new_start;
+}

mremap() doesn't allow moving multiple vmas, but it allows the movement of multi-page vmas and it also allows partial mremap()s, where it will split up a vma.

I.e. mremap() supports the shrinking (and growing) of vmas. In that case mremap() will unmap the end of the vma and will shrink the remaining vDSO vma.

Quoted 8 lines

Quoted 2 lines

Doesn't that result in a non-working vDSO that should zero out vdso_base?

Right. Now we can't completely prevent the user from shooting itself in the foot I suppose, though there is a legit usage scenario which is to move the vDSO around which it would be nice to support. I think it's reasonable to put the onus on the user here to do the right thing.

I argue we should use the right condition to clear vdso_base: if the vDSO gets at least partially unmapped. Otherwise there's little point in the whole patch: either correctly track whether the vDSO is OK, or don't ...

There's also the question of mprotect(): can users mprotect() the vDSO on PowerPC?

Quoted 4 lines

I argue we should use the right condition to clear vdso_base: if the vDSO gets at least partially unmapped. Otherwise there's little point in the whole patch: either correctly track whether the vDSO is OK, or don't ...

That's a good option, but it may be hard to achieve in the case the vDSO area has been splitted in multiple pieces.

Not sure there is a right way to handle that, here this is a best effort, allowing a process to unmap its vDSO and having the sigreturn call done through the stack area (it has to make it executable).

Anyway I'll dig into that, assuming that the vdso_base pointer should be clear if a part of the vDSO is moved or unmapped. The patch will be larger since I'll have to get the vDSO size which is private to the vdso.c file.

Quoted 2 lines

There's also the question of mprotect(): can users mprotect() the vDSO on PowerPC?

Yes, mprotect() the vDSO is allowed on PowerPC, as it is on x86, and certainly all the other architectures. Furthermore, if it is done on a partial part of the vDSO it is splitting the vma...

Quoted 13 lines · Laurent Dufour

Quoted 4 lines

I argue we should use the right condition to clear vdso_base: if the vDSO gets at least partially unmapped. Otherwise there's little point in the whole patch: either correctly track whether the vDSO is OK, or don't ...

That's a good option, but it may be hard to achieve in the case the vDSO area has been splitted in multiple pieces.

Not sure there is a right way to handle that, here this is a best effort, allowing a process to unmap its vDSO and having the sigreturn call done through the stack area (it has to make it executable).

Quoted 4 lines

Anyway I'll dig into that, assuming that the vdso_base pointer should be clear if a part of the vDSO is moved or unmapped. The patch will be larger since I'll have to get the vDSO size which is private to the vdso.c file.

At least for munmap() I don't think that's a worry: once unmapped (even if just partially), vdso_base becomes zero and won't ever be set again.

So no need to track the zillion pieces, should there be any: Humpty Dumpty won't be whole again, right?

Quoted 6 lines

Quoted 2 lines

There's also the question of mprotect(): can users mprotect() the vDSO on PowerPC?

Yes, mprotect() the vDSO is allowed on PowerPC, as it is on x86, and certainly all the other architectures. Furthermore, if it is done on a partial part of the vDSO it is splitting the vma...

btw., CRIU's main purpose here is to reconstruct a vDSO that was originally randomized, but whose address must now be reproduced as-is, right?

In that sense detecting the 'good' mremap() as your patch does should do the trick and is certainly not objectionable IMHO - I was just wondering whether we could make a perfect job very simply.

arch/powerpc/kernel/vdso.c +25 -0

+{
+	unsigned long vdso_end, vdso_start;
+
+	if (!mm->context.vdso_base)
+		return;
+	vdso_start = mm->context.vdso_base;
+
+#ifdef CONFIG_PPC64
+	/* Calling is_32bit_task() implies that we are dealing with the
+	 * current process memory. If there is a call path where mm is not
+	 * owned by the current task, then we'll have need to store the
+	 * vDSO size in the mm->context.
+	 */
+	BUG_ON(current->mm != mm);
+	if (is_32bit_task())
+		vdso_end = vdso_start + (vdso32_pages << PAGE_SHIFT);
+	else
+		vdso_end = vdso_start + (vdso64_pages << PAGE_SHIFT);
+#else
+	vdso_end = vdso_start + (vdso32_pages << PAGE_SHIFT);
+#endif
+	vdso_end += (1<<PAGE_SHIFT); /* data page */
+
+	/* Check if the vDSO is in the range of the remapped area */
+	if ((vdso_start <= old_start && old_start < vdso_end) ||

Quoted 30 lines · Laurent Dufour

arch/powerpc/kernel/vdso.c +30 -0

+{
+	unsigned long vdso_end, vdso_start;
+
+	if (!mm->context.vdso_base)
+		return;
+	vdso_start = mm->context.vdso_base;
+
+#ifdef CONFIG_PPC64
+	/* Calling is_32bit_task() implies that we are dealing with the
+	 * current process memory. If there is a call path where mm is not
+	 * owned by the current task, then we'll have need to store the
+	 * vDSO size in the mm->context.
+	 */
+	BUG_ON(current->mm != mm);
+	if (is_32bit_task())
+		vdso_end = vdso_start + (vdso32_pages << PAGE_SHIFT);
+	else
+		vdso_end = vdso_start + (vdso64_pages << PAGE_SHIFT);
+#else
+	vdso_end = vdso_start + (vdso32_pages << PAGE_SHIFT);
+#endif
+	vdso_end += (1<<PAGE_SHIFT); /* data page */
+
+	/* Check if the vDSO is in the range of the remapped area */
+	if ((vdso_start <= old_start && old_start < vdso_end) ||
+	    (vdso_start < old_end && old_end <= vdso_end)  ||
+	    (old_start <= vdso_start && vdso_start < old_end)) {
+		/* Update vdso_base if the vDSO is entirely moved. */
+		if (old_start == vdso_start && old_end == vdso_end &&
+		    (old_end - old_start) == (new_end - new_start))

arch/powerpc/kernel/vdso.c int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp) · line 323

Quoted 5 lines

arch/powerpc/kernel/vdso.c +5 -0

+			mm->context.vdso_base = new_start;
+		else
+			mm->context.vdso_base = 0;
+	}
+}

Oh my, that really looks awfully complex, as you predicted, and right in every mremap() call.

I'm fine with your original, imperfect, KISS approach. Sorry about this detour ...

Reviewed-by Ingo Molnar <[email protected]>

Quoted 24 lines · Benjamin Herrenschmidt

Quoted 23 lines · Ingo Molnar

Quoted 8 lines · Ingo Molnar

Quoted 8 lines

arch/powerpc/include/asm/mmu_context.h +8 -0

+#define __HAVE_ARCH_REMAP
+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.

Quoted 8 lines

arch/powerpc/include/asm/mmu_context.h static inline void enter_lazy_tlb(struct mm_struct *mm, · line 144

Quoted 4 lines

arch/powerpc/include/asm/mmu_context.h +4 -0

+	 */
+	if (old_start == mm->context.vdso_base)
+		mm->context.vdso_base = new_start;
+}

mremap() doesn't allow moving multiple vmas, but it allows the movement of multi-page vmas and it also allows partial mremap()s, where it will split up a vma.

I.e. mremap() supports the shrinking (and growing) of vmas. In that case mremap() will unmap the end of the vma and will shrink the remaining vDSO vma.

Quoted 8 lines

Quoted 2 lines

Doesn't that result in a non-working vDSO that should zero out vdso_base?

Right. Now we can't completely prevent the user from shooting itself in the foot I suppose, though there is a legit usage scenario which is to move the vDSO around which it would be nice to support. I think it's reasonable to put the onus on the user here to do the right thing.

I argue we should use the right condition to clear vdso_base: if the vDSO gets at least partially unmapped. Otherwise there's little point in the whole patch: either correctly track whether the vDSO is OK, or don't ...

There's also the question of mprotect(): can users mprotect() the vDSO on PowerPC?

arch/powerpc/include/asm/mmu_context.h static inline void enter_lazy_tlb(struct mm_struct *mm, · line 126

Quoted 7 lines · Laurent Dufour

arch/powerpc/include/asm/mmu_context.h +7 -0

+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;
+}

So AFAICS PowerPC can have multi-page vDSOs, right?

So what happens if I munmap() the middle or end of the vDSO? The above condition only seems to cover unmaps that affect the first page. I think 'affects any page' ought to be the right condition? (But I know nothing about PowerPC so I might be wrong.)

arch/powerpc/include/asm/mmu_context.h static inline void enter_lazy_tlb(struct mm_struct *mm, · line 144

Quoted 13 lines

arch/powerpc/include/asm/mmu_context.h +12 -0

+#define __HAVE_ARCH_REMAP
+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 (old_start == mm->context.vdso_base)
+		mm->context.vdso_base = new_start;
+}

mremap() doesn't allow moving multiple vmas, but it allows the movement of multi-page vmas and it also allows partial mremap()s, where it will split up a vma.

In particular, what happens if an mremap() is done with old_start == vdso_base, but a shorter end than the end of the vDSO? (i.e. a partial mremap() with fewer pages than the vDSO size)

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Quoted 17 lines

arch/powerpc/include/asm/mmu_context.h static inline void enter_lazy_tlb(struct mm_struct *mm, · line 144

Quoted 12 lines

arch/powerpc/include/asm/mmu_context.h +12 -0

+#define __HAVE_ARCH_REMAP
+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 (old_start == mm->context.vdso_base)
+		mm->context.vdso_base = new_start;
+}

mremap() doesn't allow moving multiple vmas, but it allows the movement of multi-page vmas and it also allows partial mremap()s, where it will split up a vma.

Quoted 3 lines

In particular, what happens if an mremap() is done with old_start == vdso_base, but a shorter end than the end of the vDSO? (i.e. a partial mremap() with fewer pages than the vDSO size)

Is there a way to forbid splitting ? Does x86 deal with that case at all or it doesn't have to for some other reason ?

Quoted 21 lines · Benjamin Herrenschmidt

Quoted 20 lines

arch/powerpc/include/asm/mmu_context.h static inline void enter_lazy_tlb(struct mm_struct *mm, · line 144

Quoted 12 lines

arch/powerpc/include/asm/mmu_context.h +12 -0

+#define __HAVE_ARCH_REMAP
+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 (old_start == mm->context.vdso_base)
+		mm->context.vdso_base = new_start;
+}

mremap() doesn't allow moving multiple vmas, but it allows the movement of multi-page vmas and it also allows partial mremap()s, where it will split up a vma.

In particular, what happens if an mremap() is done with old_start == vdso_base, but a shorter end than the end of the vDSO? (i.e. a partial mremap() with fewer pages than the vDSO size)

Quoted 2 lines

Is there a way to forbid splitting ? Does x86 deal with that case at all or it doesn't have to for some other reason ?

So we use _install_special_mapping() - maybe PowerPC does that too? That adds VM_DONTEXPAND which ought to prevent some - but not all - of the VM API weirdnesses.

On x86 we'll just dump core if someone unmaps the vdso.

CRIU is recreating the process memory layout by remapping the checkpointee memory area on top of the current process (criu). This includes remapping the vDSO to the place it has at checkpoint time.

However some architectures like powerpc are keeping a reference to the vDSO base address to build the signal return stack frame by calling the vDSO sigreturn service. So once the vDSO has been moved, this reference is no more valid and the signal frame built later are not usable.

This patch serie is introducing a new mm hook 'arch_remap' which is called when mremap is done and the mm lock still hold. The next patch is adding the vDSO remap and unmap tracking to the powerpc architecture.

Laurent Dufour (2):
mm: Introducing arch_remap hook
powerpc/mm: Tracking vDSO remap

 arch/powerpc/include/asm/mmu_context.h   | 35 +++++++++++++++++++++++++++++++-
 arch/s390/include/asm/mmu_context.h      |  6 ++++++
 arch/um/include/asm/mmu_context.h        |  5 +++++
 arch/unicore32/include/asm/mmu_context.h |  6 ++++++
 arch/x86/include/asm/mmu_context.h       |  6 ++++++
 include/asm-generic/mm_hooks.h           |  6 ++++++
 mm/mremap.c                              |  9 ++++++--
 7 files changed, 70 insertions(+), 3 deletions(-)