From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f71.google.com (mail-oi0-f71.google.com [209.85.218.71]) by kanga.kvack.org (Postfix) with ESMTP id 7FC3B828E1 for ; Tue, 28 Jun 2016 07:37:00 -0400 (EDT) Received: by mail-oi0-f71.google.com with SMTP id u81so21791025oia.3 for ; Tue, 28 Jun 2016 04:37:00 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0113.outbound.protection.outlook.com. [157.55.234.113]) by mx.google.com with ESMTPS id h77si80265oib.276.2016.06.28.04.36.59 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 28 Jun 2016 04:36:59 -0700 (PDT) From: Dmitry Safonov Subject: [PATCHv10 0/2] mremap vDSO for 32-bit Date: Tue, 28 Jun 2016 14:35:37 +0300 Message-ID: <20160628113539.13606-1-dsafonov@virtuozzo.com> MIME-Version: 1.0 Content-Type: text/plain Sender: owner-linux-mm@kvack.org List-ID: To: linux-kernel@vger.kernel.org Cc: 0x7f454c46@gmail.com, mingo@redhat.com, luto@kernel.org, linux-mm@kvack.org, Dmitry Safonov 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: v10: run selftest after fork() and treat child segfaults for a nice error reports. 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 | 3 +- tools/testing/selftests/x86/test_mremap_vdso.c | 111 +++++++++++++++++++++++++ 5 files changed, 168 insertions(+), 6 deletions(-) create mode 100644 tools/testing/selftests/x86/test_mremap_vdso.c -- 2.9.0 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-f197.google.com (mail-ob0-f197.google.com [209.85.214.197]) by kanga.kvack.org (Postfix) with ESMTP id 3A564828E1 for ; Tue, 28 Jun 2016 07:37:01 -0400 (EDT) Received: by mail-ob0-f197.google.com with SMTP id at7so27574417obd.1 for ; Tue, 28 Jun 2016 04:37:01 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0113.outbound.protection.outlook.com. [157.55.234.113]) by mx.google.com with ESMTPS id h77si80265oib.276.2016.06.28.04.37.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 28 Jun 2016 04:37:00 -0700 (PDT) From: Dmitry Safonov Subject: [PATCHv10 1/2] x86/vdso: add mremap hook to vm_special_mapping Date: Tue, 28 Jun 2016 14:35:38 +0300 Message-ID: <20160628113539.13606-2-dsafonov@virtuozzo.com> In-Reply-To: <20160628113539.13606-1-dsafonov@virtuozzo.com> References: <20160628113539.13606-1-dsafonov@virtuozzo.com> MIME-Version: 1.0 Content-Type: text/plain Sender: owner-linux-mm@kvack.org List-ID: To: linux-kernel@vger.kernel.org Cc: 0x7f454c46@gmail.com, mingo@redhat.com, luto@kernel.org, linux-mm@kvack.org, Dmitry Safonov , Thomas Gleixner , "H. Peter Anvin" , x86@kernel.org 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 Cc: Andy Lutomirski Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: x86@kernel.org Cc: linux-mm@kvack.org Acked-by: Andy Lutomirski --- 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 #include #include +#include #include #include #include @@ -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 e093e1d3285b..79472b22d23f 100644 --- a/include/linux/mm_types.h +++ b/include/linux/mm_types.h @@ -595,6 +595,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 25c2b4e0fbdc..86b18f334f4f 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -2961,9 +2961,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.9.0 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-f69.google.com (mail-it0-f69.google.com [209.85.214.69]) by kanga.kvack.org (Postfix) with ESMTP id 82D32828E1 for ; Tue, 28 Jun 2016 07:37:03 -0400 (EDT) Received: by mail-it0-f69.google.com with SMTP id f6so29397408ith.1 for ; Tue, 28 Jun 2016 04:37:03 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0110.outbound.protection.outlook.com. [157.55.234.110]) by mx.google.com with ESMTPS id p189si15331091oig.146.2016.06.28.04.37.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 28 Jun 2016 04:37:02 -0700 (PDT) From: Dmitry Safonov Subject: [PATCHv10 2/2] selftest/x86: add mremap vdso test Date: Tue, 28 Jun 2016 14:35:39 +0300 Message-ID: <20160628113539.13606-3-dsafonov@virtuozzo.com> In-Reply-To: <20160628113539.13606-1-dsafonov@virtuozzo.com> References: <20160628113539.13606-1-dsafonov@virtuozzo.com> MIME-Version: 1.0 Content-Type: text/plain Sender: owner-linux-mm@kvack.org List-ID: To: linux-kernel@vger.kernel.org Cc: 0x7f454c46@gmail.com, mingo@redhat.com, luto@kernel.org, linux-mm@kvack.org, Dmitry Safonov , Thomas Gleixner , "H. Peter Anvin" , Shuah Khan , x86@kernel.org, linux-kselftest@vger.kernel.org Should print on success: [root@localhost ~]# ./test_mremap_vdso_32 AT_SYSINFO_EHDR is 0xf773f000 [NOTE] Moving vDSO: [f773f000, f7740000] -> [a000000, a001000] [OK] Or print that mremap for vDSO is unsupported: [root@localhost ~]# ./test_mremap_vdso_32 AT_SYSINFO_EHDR is 0xf773c000 [NOTE] Moving vDSO: [0xf773c000, 0xf773d000] -> [0xf7737000, 0xf7738000] [FAIL] mremap() of the vDSO does not work on this kernel! Cc: Andy Lutomirski Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: Shuah Khan Cc: x86@kernel.org Cc: linux-kselftest@vger.kernel.org Suggested-by: Andy Lutomirski Signed-off-by: Dmitry Safonov --- tools/testing/selftests/x86/Makefile | 3 +- tools/testing/selftests/x86/test_mremap_vdso.c | 111 +++++++++++++++++++++++++ 2 files changed, 113 insertions(+), 1 deletion(-) create mode 100644 tools/testing/selftests/x86/test_mremap_vdso.c diff --git a/tools/testing/selftests/x86/Makefile b/tools/testing/selftests/x86/Makefile index abe9c35c1cb6..c701349d4920 100644 --- a/tools/testing/selftests/x86/Makefile +++ b/tools/testing/selftests/x86/Makefile @@ -5,7 +5,8 @@ include ../lib.mk .PHONY: all all_32 all_64 warn_32bit_failure clean TARGETS_C_BOTHBITS := single_step_syscall sysret_ss_attrs syscall_nt ptrace_syscall \ - check_initial_reg_state sigreturn ldt_gdt iopl mpx-mini-test + check_initial_reg_state sigreturn ldt_gdt iopl mpx-mini-test \ + test_mremap_vdso TARGETS_C_32BIT_ONLY := entry_from_vm86 syscall_arg_fault test_syscall_vdso unwind_vdso \ test_FCMOV test_FCOMI test_FISTTP \ vdso_restorer diff --git a/tools/testing/selftests/x86/test_mremap_vdso.c b/tools/testing/selftests/x86/test_mremap_vdso.c new file mode 100644 index 000000000000..a489a2410664 --- /dev/null +++ b/tools/testing/selftests/x86/test_mremap_vdso.c @@ -0,0 +1,111 @@ +/* + * 32-bit test to check vdso mremap. + * + * Copyright (c) 2016 Dmitry Safonov + * Suggested-by: Andrew Lutomirski + * + * This program is free software; you can redistribute it and/or modify + * it under the terms and conditions of the GNU General Public License, + * version 2, as published by the Free Software Foundation. + * + * This program is distributed in the hope it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + */ +/* + * Can be built statically: + * gcc -Os -Wall -static -m32 test_mremap_vdso.c + */ +#define _GNU_SOURCE +#include +#include +#include +#include + +#include +#include +#include +#include + +#define PAGE_SIZE 4096 + +static int try_to_remap(void *vdso_addr, unsigned long size) +{ + void *dest_addr, *new_addr; + + /* Searching for memory location where to remap */ + dest_addr = mmap(0, size, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0); + if (dest_addr == MAP_FAILED) { + printf("[WARN]\tmmap failed (%d): %m\n", errno); + return 0; + } + + printf("[NOTE]\tMoving vDSO: [%p, %#lx] -> [%p, %#lx]\n", + vdso_addr, (unsigned long)vdso_addr + size, + dest_addr, (unsigned long)dest_addr + size); + fflush(stdout); + + new_addr = mremap(vdso_addr, size, size, + MREMAP_FIXED|MREMAP_MAYMOVE, dest_addr); + if ((unsigned long)new_addr == (unsigned long)-1) { + munmap(dest_addr, size); + if (errno == EINVAL) { + printf("[NOTE]\tvDSO partial move failed, will try with bigger size\n"); + return -1; /* Retry with larger */ + } + printf("[FAIL]\tmremap failed (%d): %m\n", errno); + return 1; + } + + return 0; + +} + +int main(int argc, char **argv, char **envp) +{ + pid_t child; + + child = fork(); + if (child == -1) { + printf("[WARN]\tfailed to fork (%d): %m\n", errno); + return 1; + } + + if (child == 0) { + unsigned long vdso_size = PAGE_SIZE; + unsigned long auxval; + int ret = -1; + + auxval = getauxval(AT_SYSINFO_EHDR); + printf("\tAT_SYSINFO_EHDR is %#lx\n", auxval); + if (!auxval || auxval == -ENOENT) { + printf("[WARN]\tgetauxval failed\n"); + return 0; + } + + /* Simpler than parsing ELF header */ + while (ret < 0) { + ret = try_to_remap((void *)auxval, vdso_size); + vdso_size += PAGE_SIZE; + } + + /* Glibc is likely to explode now - exit with raw syscall */ + asm volatile ("int $0x80" : : "a" (__NR_exit), "b" (!!ret)); + } else { + int status; + + if (waitpid(child, &status, 0) != child || + !WIFEXITED(status)) { + printf("[FAIL]\tmremap() of the vDSO does not work on this kernel!\n"); + return 1; + } else if (WEXITSTATUS(status) != 0) { + printf("[FAIL]\tChild failed with %d\n", + WEXITSTATUS(status)); + return 1; + } + printf("[OK]\n"); + } + + return 0; +} -- 2.9.0 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-f198.google.com (mail-qk0-f198.google.com [209.85.220.198]) by kanga.kvack.org (Postfix) with ESMTP id 5971D828E1 for ; Wed, 6 Jul 2016 10:04:12 -0400 (EDT) Received: by mail-qk0-f198.google.com with SMTP id e3so439699896qkd.2 for ; Wed, 06 Jul 2016 07:04:12 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com. [2607:f8b0:400c:c05::22a]) by mx.google.com with ESMTPS id 31si909828uaw.127.2016.07.06.07.04.11 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Jul 2016 07:04:11 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id b192so6187050vke.0 for ; Wed, 06 Jul 2016 07:04:11 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20160628113539.13606-2-dsafonov@virtuozzo.com> References: <20160628113539.13606-1-dsafonov@virtuozzo.com> <20160628113539.13606-2-dsafonov@virtuozzo.com> From: Andy Lutomirski Date: Wed, 6 Jul 2016 07:03:48 -0700 Message-ID: Subject: Re: [PATCHv10 1/2] x86/vdso: add mremap hook to vm_special_mapping Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: Dmitry Safonov Cc: "linux-kernel@vger.kernel.org" , Dmitry Safonov <0x7f454c46@gmail.com>, Ingo Molnar , Andrew Lutomirski , "linux-mm@kvack.org" , Thomas Gleixner , "H. Peter Anvin" , X86 ML On Tue, Jun 28, 2016 at 4:35 AM, Dmitry Safonov wrote: > 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 Acked-by: Andy Lutomirski -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw0-f199.google.com (mail-yw0-f199.google.com [209.85.161.199]) by kanga.kvack.org (Postfix) with ESMTP id CD1046B0260 for ; Fri, 8 Jul 2016 08:17:07 -0400 (EDT) Received: by mail-yw0-f199.google.com with SMTP id l125so82886503ywb.2 for ; Fri, 08 Jul 2016 05:17:07 -0700 (PDT) Received: from mail-qk0-x244.google.com (mail-qk0-x244.google.com. [2607:f8b0:400d:c09::244]) by mx.google.com with ESMTPS id l62si1851481qke.229.2016.07.08.05.17.07 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Jul 2016 05:17:07 -0700 (PDT) Received: by mail-qk0-x244.google.com with SMTP id r68so8299302qka.3 for ; Fri, 08 Jul 2016 05:17:07 -0700 (PDT) Date: Fri, 8 Jul 2016 14:17:04 +0200 From: Ingo Molnar Subject: Re: [PATCHv10 2/2] selftest/x86: add mremap vdso test Message-ID: <20160708121704.GA31371@gmail.com> References: <20160628113539.13606-1-dsafonov@virtuozzo.com> <20160628113539.13606-3-dsafonov@virtuozzo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160628113539.13606-3-dsafonov@virtuozzo.com> Sender: owner-linux-mm@kvack.org List-ID: To: Dmitry Safonov Cc: linux-kernel@vger.kernel.org, 0x7f454c46@gmail.com, mingo@redhat.com, luto@kernel.org, linux-mm@kvack.org, Thomas Gleixner , "H. Peter Anvin" , Shuah Khan , x86@kernel.org, linux-kselftest@vger.kernel.org * Dmitry Safonov wrote: > Or print that mremap for vDSO is unsupported: > [root@localhost ~]# ./test_mremap_vdso_32 > AT_SYSINFO_EHDR is 0xf773c000 > [NOTE] Moving vDSO: [0xf773c000, 0xf773d000] -> [0xf7737000, 0xf7738000] > [FAIL] mremap() of the vDSO does not work on this kernel! Hm, I tried this on a 64-bit kernel and got: triton:~/tip/tools/testing/selftests/x86> ./test_mremap_vdso_32 AT_SYSINFO_EHDR is 0xf7773000 [NOTE] Moving vDSO: [0xf7773000, 0xf7774000] -> [0xf776e000, 0xf776f000] Segmentation fault Thanks, Ingo -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752574AbcF1LhJ (ORCPT ); Tue, 28 Jun 2016 07:37:09 -0400 Received: from mail-db3on0122.outbound.protection.outlook.com ([157.55.234.122]:21403 "EHLO emea01-db3-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752342AbcF1LhE (ORCPT ); Tue, 28 Jun 2016 07:37:04 -0400 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=dsafonov@virtuozzo.com; From: Dmitry Safonov To: CC: <0x7f454c46@gmail.com>, , , , Dmitry Safonov , Thomas Gleixner , "H. Peter Anvin" , Subject: [PATCHv10 1/2] x86/vdso: add mremap hook to vm_special_mapping Date: Tue, 28 Jun 2016 14:35:38 +0300 Message-ID: <20160628113539.13606-2-dsafonov@virtuozzo.com> X-Mailer: git-send-email 2.9.0 In-Reply-To: <20160628113539.13606-1-dsafonov@virtuozzo.com> References: <20160628113539.13606-1-dsafonov@virtuozzo.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [195.214.232.10] X-ClientProxiedBy: AMSPR02CA0032.eurprd02.prod.outlook.com (10.242.225.160) To HE1PR0801MB1737.eurprd08.prod.outlook.com (10.168.149.149) X-MS-Office365-Filtering-Correlation-Id: 223899c1-b06e-45e4-7bfd-08d39f4883f0 X-Microsoft-Exchange-Diagnostics: 1;HE1PR0801MB1737;2:BosetKZss8WKvzTfwVz0bqolfutcA2YWG76UUQU8EPeItq+Zux8jbuo8W8GsakCXhNAERcQ07sRzEkiJN5yKnvFwbVbkzej+0VXqOiAESeoAYoYsnuCcIYgPaOkZMdmSlrgcd7xn29m1D2wNV0Togj4LbtDU3bmWNESerCtqYNipEJjLAXi1fpqxojFK045n;3:tdLVOwAQzoB9O6mETNkH5X59Qi4M84VfRX8Zak6bnGdUjXReI27uDmqV/ixibg5PpU623h6QoF2W2seg3SmjUa34T77BuGMj7d3XstrUDq4hO327XUqK+eqhaHxwyXFs X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0801MB1737; X-Microsoft-Exchange-Diagnostics: 1;HE1PR0801MB1737;25:YHHVc/J6JE2w+zTJaVkuj5ufiqEz7sgUiWLLvhuvjqQxTUoyp0usnh9U2ThFmWLbdLcRRJQpsR4CfE6BKim1WdLV9jlIyGdBm1tYBUoZrTdew3wElKE4/abKuP4GHxxpJCDVRSKAkemWsMFJK2EehhIyyhlMJcysUQ7PEwHEGgAAnTCXNo6Mx9bULnrTVGqGVG8DXHkH/Sui2AlUMWWfy+o34GgaJe0JJ6GuUxzUDawOK853XBBB7XfMZDSFS2Z42x8unfiY6ebg9d/i0WqEyrnAuSxnDPpMzkggl+VkMgA3+ao00n0Wl3/e/C7KrT7Z+ZhFUyy5z6DllsuM04pbapVB+I3V9Kr6ZRKZg1twluyTG9I/MOhqh1rKGPRQRphs9tCpWjwLuLYdI5imrwq+MqiAWGWf1QoP8y+0JT4hchn1z/d58Ba8WPwE8NJtl5mosbq8Nl6BEqWQigN9dn/rfbpxPao0P2/hZBNooOu2AQpsJSZaPBURY+GwKawuapTkS02nOOZH6pIUCAQhV7k7vNQMe6aTWHAkNL2b0GEkFwenrGSpnSxqe8CkmDTCzUqyKgKpo0lb6qGStj54PWZVZQgfubJ8MbBKrPi4HJ7bHlMPxrMVI0cmlrADucYvmkpmCBHb8H0uWlc7kgqPv2QUMMmSyYeUk1Fupr15qJLi2EH1DllOnja3aMtVSpMb8XLd+jGYsYyZjRHo2we3V0zxrw== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(278428928389397)(17755550239193); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040130)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041072)(6043046);SRVR:HE1PR0801MB1737;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0801MB1737; X-Microsoft-Exchange-Diagnostics: 1;HE1PR0801MB1737;4:mmgHROQLv3naaQiwmKJZFebm6NZEbAlQBGlFIKVo3Ywm4dmxs0jOi5Qp5HTh/9nSxKkP/TEFNClAWTwLfHDHLyT8Baryl03Ft1A5SL2lS6w+ByS+muAUK/5kUkWSp0Eo9T00ziDDZ75ciS5vXAS9X63Ubs2KLTRpYbXyOYCpG7SbfmMUUtdylUP/yT7psCBbttgqVPH7b2DvD4SE0kpMl7FsmHmw9Qp41D2PQDmK6lB9qY9uqQF4M8qEFtqB2pQepGbIAmnaVXzQ3xVXreOid7ifAOfX+ZE+damg6/ZrfPjXZkaDhraUwHSz9eIA7CzU7BbhOIk5qKP6yB1lBA+GNs6+T1uICu1jjQZR8GL6AI7QR83oeP5Pv9inQqGVC4/zvxPsS7zZD/rP1AoGVV/aKl3ywgoFxuqD/HWoFw6XPSKyawLe6Yt/ftw0/eREsxNg95ynlyCzsKo27FvBgGekfilNmANhC+dpngXhpf09RI6kxkvfPzuoVtk2bPHYLr3z X-Forefront-PRVS: 0987ACA2E2 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(4630300001)(6009001)(7916002)(199003)(189002)(3846002)(105586002)(586003)(92566002)(53416004)(6116002)(5003940100001)(69596002)(19580405001)(19580395003)(7736002)(305945005)(81156014)(77096005)(81166006)(106356001)(8676002)(66066001)(47776003)(42186005)(1076002)(68736007)(33646002)(76176999)(7846002)(50466002)(97736004)(50226002)(229853001)(2906002)(101416001)(2351001)(2950100001)(110136002)(48376002)(4326007)(36756003)(189998001)(86362001)(575784001)(50986999);DIR:OUT;SFP:1102;SCL:1;SRVR:HE1PR0801MB1737;H:dsafonov.sw.ru;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;HE1PR0801MB1737;23:oVyrY4aX8SlgjNMhXhf8gsPNkBaDFbz3Vm89rA1?= =?us-ascii?Q?jK8/mogjTuJymGn45Z3oOEuwmw6KSQkdjreLMG1IIImlpefzcta3KttP4eH8?= =?us-ascii?Q?pac8NiZakGYW9CUKZwKeGc5vDxwaFHx7IovbPYJPf1mdDqLHxrq3FRARQbfK?= =?us-ascii?Q?WhYre04+qGj34SHcDTw8F919ICcTIaczYjeObJczR1lbBfMuVoTMFiOxoPXb?= =?us-ascii?Q?LUNNbfFmNkOB4tucoZzNqlfvfk9F660ZO/stG1Zgl56aR7YdW7m+JQr2LaTA?= =?us-ascii?Q?PR4/JC/nzH7RviOVYo546TL5cqjZoaFO9nPnHEUn2BEiwZ2xSwOOARqTQPod?= =?us-ascii?Q?oQGVA4hwRWVv4zBOr7rA3gmxe5Vu2+qBdrFkPzMcaGHKdzxCljy7BTyHnMW2?= =?us-ascii?Q?b2X6AH5H3y7KLmuOySC3TPc4FvBpftpH5bI0OlEDI1tYjDkIpU9YMur8yixC?= =?us-ascii?Q?P76/hRTRfIY7bq49gF6h+VJt06M0oS8kGkh1EVRFXVmWB+9V8kk9aW9gAdsL?= =?us-ascii?Q?19Yj+KPjBKq7hHonFic1KH6jEYBQnrj0FjeVtZt/VLFuTixCcLs+bGEZZkvC?= =?us-ascii?Q?gaIz9pdJlE6d4fSpCyOUrDm/RMzI+UFRgXg5RADUrwp71N+Bn0655LfegtFV?= =?us-ascii?Q?sjftGMNN2Xg41ucFtBxnccU1h3PtSs+4p1fENIggL7TNYcLcaj8ZCmjDJdO9?= =?us-ascii?Q?QrghiMdQThZ/ne6VIXejZt4JkzgdAwaDh4rrLZQn7d1fQ7cl8NqhdBAsI9DO?= =?us-ascii?Q?i0ZxKOaj+aKlJn3VIszYaL/W3U+GKCddPJl3FUtst0yd1SR/vD57RoqMdos/?= =?us-ascii?Q?rC4rTvNGoMfXFoCT/afKNoCl75PNPi8THHvNDCNw9TwWhfsZjv43bGnuMu7+?= =?us-ascii?Q?28x3tSYz+rmTUr3I/AwJykoy0FukgDVcz5JOPU1SZPxK2GyKGubn7yrf+rlN?= =?us-ascii?Q?YdBCvkIcAjCdPCc/aNJuq+jz9dGZ/ALTSDeX/yNPYZfOPCMqvdndBohxHAyE?= =?us-ascii?Q?2pDNsHbCGv+eNXhZYSXWOeEZS2D194xXcJl9UtHWeK30V7uh3o0uYPxiYxo9?= =?us-ascii?Q?gecH9iCo2Op+eBLX4SmF36tbgBRY5rl7Pow2qdrustvn1drjQY1GSpuGpDr7?= =?us-ascii?Q?To1HNIIm1nxMfEgoMr0bayFkZj2Ce6EDZbYF4t2Yxw8/1/H9pc1V22g=3D?= =?us-ascii?Q?=3D?= X-Microsoft-Exchange-Diagnostics: 1;HE1PR0801MB1737;6:iZjwK90pEIuKg4nBPjdAgHPhaMxUsZuabLFCHmJ9IoT4RmBockhSnYllG+qxMDZ4QNqtwh+SjPR0SMCd3nQLJvsUu8Ue4QXhiJrwnf/N5+vYxkPGAhCz3mfBadQuJ0DyXFsvSYG3bjWBF3SsDz+dQaHIRNAilZldMjqCYrcttlshMdI4x/tNUbWXZwUnXIccnx2gB1MPtPWasA6qCoNUFe9TdD0CMPkndFBc9DET96X2/tXNXYBhhaxfIxpfmzViCtH/flsa2ukl+IISJWG2HfkUR4CiCd3G9aWxoqHGEmL4qv828PuB3MKRYIv2XipIfZ9D2gqw9R5hDtpwa9FB8w==;5:2wPXUUwTRhGs/Yq3S6n+Nizv5sArQNAdAv4Y7rfDv/EuQ39XOSbopU4W6aEQ1HkyeEDto68BdvWCeGRKhWV7yC7zLXmJOmBguJVQ0tlEMaRrz5RAKYw9QEJdwCjePx1JZyGV6chNIiVqJ1kYNC7Fkg==;24:e18kuf2JMxlRlRytyEM20xe5OrUnYdloTTViFMWyaVPrNwj3M+Pawe6cyREDqQ9mnha1tdxJjJH7KvbRPICp0rJGssT+FprYBQjW2pnXog0=;7:yYfDWIX5FmdVj+5Mul66o2wDSqhcX5cf3KxMfPTC7PPtkhXJ3GGjPenPmDQzpczRa5MxdI14jNCk7Gt0Q2AwQpCVgbE6wkBOcxFFl4osKlVJz1aBrVpu3i6gT4PjySTepaOwKTnhcHbsxw6X78xzM0somz/YI6uF0OwvPh4wbiTYpj/KtwqUohfLM2s6UBqlfgFLg+sEOzgTPV8PWm5lrCZAI1ezIBX+hziEo33KWn2pKZF8hkRnJCF2/kn8XzgFINZrVAJPdPc0NugcyHGl5A== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;HE1PR0801MB1737;20:ATHvyqc8F3Jl04KFI3msc/uVnWJroqVFvBbDUKEQzCrI5VIlQ278qaMJtmeREAEQWY8D8CLGqsM8NiYkuMfvWl4flImA+CCDoKCIFVBSCSoySUXVPEcnBAyio+4xuGbpA2DSyWq5VKMjoaY1cGdcnPDZhNpiapuc9D4JtBF/ZUA= X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jun 2016 11:36:57.7219 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0801MB1737 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 Cc: Andy Lutomirski Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: x86@kernel.org Cc: linux-mm@kvack.org Acked-by: Andy Lutomirski --- 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 #include #include +#include #include #include #include @@ -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 e093e1d3285b..79472b22d23f 100644 --- a/include/linux/mm_types.h +++ b/include/linux/mm_types.h @@ -595,6 +595,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 25c2b4e0fbdc..86b18f334f4f 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -2961,9 +2961,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.9.0 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752469AbcF1LiV (ORCPT ); Tue, 28 Jun 2016 07:38:21 -0400 Received: from mail-db3on0122.outbound.protection.outlook.com ([157.55.234.122]:21403 "EHLO emea01-db3-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752466AbcF1LhG (ORCPT ); Tue, 28 Jun 2016 07:37:06 -0400 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=dsafonov@virtuozzo.com; From: Dmitry Safonov To: CC: <0x7f454c46@gmail.com>, , , , Dmitry Safonov , Thomas Gleixner , "H. Peter Anvin" , Shuah Khan , , Subject: [PATCHv10 2/2] selftest/x86: add mremap vdso test Date: Tue, 28 Jun 2016 14:35:39 +0300 Message-ID: <20160628113539.13606-3-dsafonov@virtuozzo.com> X-Mailer: git-send-email 2.9.0 In-Reply-To: <20160628113539.13606-1-dsafonov@virtuozzo.com> References: <20160628113539.13606-1-dsafonov@virtuozzo.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [195.214.232.10] X-ClientProxiedBy: AMSPR02CA0032.eurprd02.prod.outlook.com (10.242.225.160) To HE1PR0801MB1737.eurprd08.prod.outlook.com (10.168.149.149) X-MS-Office365-Filtering-Correlation-Id: df298bc1-5836-4c2a-3373-08d39f488510 X-Microsoft-Exchange-Diagnostics: 1;HE1PR0801MB1737;2:GYtSTwFjAeI3juqofgnatb+LLl1aiDCzVi+R/QSe8Dgos2cvQmah+856n9tQ15EXAkOTZlmyLnoLU8RpSjv3SuxmcO05OL/kEUUNb+fi19+UEJ4mwpPiKJZnOBgiJkhqBOpEQzdJHaPnZ15QVS2exUssgFyZ/qcSke0HMZNgstLQI+WoeGdQNMEd3kBl2Sp6;3:QuoPwJ2B8jiSkfhcAGlaXPtseb2n8/Vs9HMJ15aES33muGx3rgJCs1EEJ0LvGmFvVigtNOFM5zasOFHmdespDUxWcubWBTmFG13Vn30EkoZcWyC6YRxYLpEQyDiEmZmy X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0801MB1737; X-Microsoft-Exchange-Diagnostics: 1;HE1PR0801MB1737;25:GA9UXjF6vUQg05E8gTcEPPTWg9xA1a9011HO4hVQFv2hzlMVHKphYcCpqeCW5BF02oDgtzCnyX288cEqpt/Ce/j9A3g2dUMoGCMyYKScE7GTJ8tQt54s5wPA6+yYMCvK7AAdQG5ffxCVBfZw7sjMpqPdeFuxtzzwcaI6Plj57QRd2+5wBLh8fvwsKlcc8lvj7R2z1aQBeW9Jli6c8NJ6RFnfyFSm7mY1JWD63D3GDGgjw5CQKjrf4u3bdnFHMQ2ydJ6oUpMkUg5mz1MwoBi7Dt4ELpYwWOBsHDv7yNDiZMzKNmfQs9bpNj20xAmT8wBZyR22bx5/FtujdfCS54lMLxG/Gou/RiDqKbxl7Nz3DuCSstwl4I8zR0MmqWoWoqPPRSWulTopghfsp4qkDDVUesecAuKGFcgb0V376O51s9rcMz5Dz48TuWSznxCKQMAdkARGLRnt+dXiBbYMwe0X2tTNdBj+vlx7fcWCzmdQBwKaIWt8dCCGwnj9xj8Q5A3ZnvspJWn3+dUnqb32TrRF65SlMKuDEfJT6j6Ejv9cRqAJhdwqYcRJt37acDw8VkK9qmiCeH2QVnfa4otg+BLdBLvJt/wGemBbHh3vV7trGaUX3EbhWKrvqyen5Z6OtquxAcAlcPkRqP9YK5tibEu/Q+R/O+8ypDutw2pJrZNf58JLxq97YjwuLMoYlt5S/0eem1IFhA1INNkdpP2jwvZFPQ== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(9452136761055)(265634631926514)(7411616537696); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040130)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041072)(6043046);SRVR:HE1PR0801MB1737;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0801MB1737; X-Microsoft-Exchange-Diagnostics: 1;HE1PR0801MB1737;4:KnBg0T/tGVCOc4bRCX9LmiZP6/NQtPHrJcyijSPpmuzzUkQAbQEQjysF404ioio16fUCLBflmrhsqqezQaqy1D1HT0XSeWsrUtTpsb5oIT+xvstKMh9CmAp/IVA1YZkPYxFsILIuiUC2Dmw+TCEdJJKn80zzo9XaJrbv+2pGMkvQ6VCImrxd37JIYzxwJ8hTWslveaT9AA4Juc7L22VRiJ5fs9LLgYYExABYEPPELizi86AC/viLx0ZIH6Bp0GT2tGLD3EKwyiTqc87fr7BXwJ7OSuXHLXXQeQule8DsfEXZwoAEbhFMz4eKLs+Y0Q1lXA3DNtBCUGrz2AJgx8szJdPnLLGC352qP3t3TGiuUsSciAObKggmcTxbFOeOTS3AjdkJ+SRNWajFjZU2xt49DnOuauGrIkbuAc/2ncLllGH6skHzbFr6qhKUCu01kDI/8A1Mizp8koDrh+UTylXCaDUOKegZGOPYoVndYYJwuu8oXo9k8MSZX5QiWsc9VKkhN+l6P0n/O6U1fA9Uq4+Tio4RuMs6yT2Nt//I12g2WBg= X-Forefront-PRVS: 0987ACA2E2 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(4630300001)(6009001)(7916002)(199003)(189002)(3846002)(105586002)(586003)(92566002)(53416004)(6116002)(5003940100001)(69596002)(19580405001)(19580395003)(7736002)(305945005)(81156014)(77096005)(81166006)(106356001)(8676002)(66066001)(47776003)(42186005)(1076002)(68736007)(33646002)(76176999)(7846002)(50466002)(97736004)(50226002)(229853001)(2906002)(101416001)(2351001)(2950100001)(110136002)(48376002)(4326007)(36756003)(189998001)(86362001)(50986999)(2004002);DIR:OUT;SFP:1102;SCL:1;SRVR:HE1PR0801MB1737;H:dsafonov.sw.ru;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;HE1PR0801MB1737;23:8krIt5/8kFhCUNmd940wpkz9Xa2mHjJbPrquwPU?= =?us-ascii?Q?JShVg/qHCtjITuNgaRwO4JUypcgHCxMR0XPi8s9mSWcmPIkZFXzr4QdqoHv+?= =?us-ascii?Q?9nurQRVVq8JuwBuGF27k2Ql1Aodt9OpOT1HjlxSuxu+0y+wBZH0RAg85EUwY?= =?us-ascii?Q?PsblaqJJCfpnGtaUeeouI/gLcizR4K6GXU/hHuUpZgmUpirmE6vqZZ/3+OJM?= =?us-ascii?Q?+OzeC+A3UEK5g+sew3jiQ/kUund1n181AomfYscGJCNT8pruTEwCib3L4w8J?= =?us-ascii?Q?GUR/ev7XbkeRFk8kqrtP082FiZXg9YnY+5vvjMWB2dSHFy4Vr3WjJXRXR25v?= =?us-ascii?Q?gmowflmgtkQZvRsEvZFrZom7kbb4rtqSzpCisQa9T4onOolQoCUVGOHPZFUo?= =?us-ascii?Q?Nx9Mb0b/1CGd03LHTojJvK5PSQ9zdT67oj1hzVyQIdTbm4o3OtdmadQxakaf?= =?us-ascii?Q?DQHoJRuY76OAwbANv+hWmEFfCqPJ2fO1TU9PqmWd/ecZaKSeSdgUTZEvPkCN?= =?us-ascii?Q?CauEvQbugB1LqgxJJB7qx+wG9x3obnYVCQZ0o0VjURZoxRheQvJVHoIEsR96?= =?us-ascii?Q?hCzWF3V3bkBwQ+jyth0qor/YU9CArmHJGa7+9fnvcVEUk2wS7Bjhb12wJzTR?= =?us-ascii?Q?8pQLn1yEAQghHeYvmr3kZ7ncCJh9b8Gonr3lvMZZsn+vQEFfo04YOzNGyNW9?= =?us-ascii?Q?0z+d1mLQGhjJWdIy+DZ9CKwOicIJ4nZL1ZqHEEPJYiwv5N1Jy5OB6895sXsf?= =?us-ascii?Q?dl1kbzrFHEylrlL6iUnUB7YnDr71w9WDVaM5wbN6hZOKClttWXu29/E8TZPn?= =?us-ascii?Q?dgEd3Z4IgRd4689POjPqS+xyjkrW8blQn2+1ztnOsjrzmPpyocQIgDe0pi0D?= =?us-ascii?Q?HcVzbsboOA8smztDf0tREjmZ4unS7Y7qBuNxrC0a/b7tKDQ3IRnY6ZlAiIwo?= =?us-ascii?Q?Tc3YG79Lvg3hzJNi/TN31RXPE7n/eUPcMy8GichkizZSy/c7TpjlsyCu0Tq8?= =?us-ascii?Q?fMwkYdWk5cX5WT/P7DdKYDO74J4n3r5Y0bEqcz0wFZM8tt/I6TG8m8rIYJFw?= =?us-ascii?Q?VLXdygasMyqI4UFqh+3kSa8nj14gCKlqcuWvCLpIEVNVq+Wlw0fc23c8m/AT?= =?us-ascii?Q?1KxaJ6tbyw+Qy/yCHM/x0thoIXLdeD8xt?= X-Microsoft-Exchange-Diagnostics: 1;HE1PR0801MB1737;6:OJdjvGsq7V7Ao8OiFJJ9TkKaOp8nwNv2KiQiZUbRq6kl+UsiDXwqd1P+BMLf1fSjnHhrfC6m0Qefi0KNYfpXytVS91CL20agCq0ayg05rtrHYjQxXpusI3mzQ6IV2r0GOXce/roJEbqyj4d4NFRdwrhJIjNbuOzOC0uIQK9edOjJ0WgTiImFPNVzlW7XK+2euOzpX+bJcwgTk0JI8wADFRWmfgUI9XhHP1J0xFtRGZxbV4pOF1+33mpbY4teelx0h8d8vvueq3NhR4rzOnPBTwEqg/2f8Nik39LS26yMyxCvHD4IotH+mqq8ETCEruaiWXGDXPLYO6JuSs2+LZRIbw==;5:lHmP/GIHTNMGVmJr/92Qhtl6fqaS98LdxAOrNCshub+6JasPSEgsKw+FrLRZ+0CY8TixxLTqDJ6BgsqSBZH5uXg+Y5/zAj+9E0tJ6VIeeeJywJDwLPFhYMiWetI0M6kvvDvJYywCpr+sCNFPwvAETw==;24:kR746eHmS3fs50yfm0UFyz2ywWzGd4QcICeUdbmKCJGbaX+WGzJbwOTDk9sy6LZoP3XMKv6RGl5fRFZOExy6BOOxjdJHLFa6v3v0zU5/QMQ=;7:aJvHBrwwC6LCgDpLtiFkQ9SMq0668Lne1Es/BYpM3RqgsGCXUAr0Kx2T1TXTKuXFA2SOwutfb6eZE8Gf1pP3rvqdQ12DBQdB7NCPUZb9uF130CD4NdhkgPGNrQ+rRWrj3/uT0kaJ1DOHVBN5WfJm9T2qaG89C9xDgUnKmAU+3YwbL0ZkJmxGnClYIv3QqpIR/9UkbEEw+vdQHvR0yFhl41FB37v5j1XOi3jD8hrSo5C/pKI5MGFEoGJfoDmMcBozxPR75pALL840nMmwHgvfbw== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;HE1PR0801MB1737;20:JQTprKOBxkjKvTYN7KSB2iYwqGgauqSlA9N0gzbXXL/KID3dxD6Xhh4/HDOeT0wGByVYLIIy5CJKKpUbMsExpkriknnYmq6U3eJZwrLS8vQnRZqZ16ve5BPDZsL9EYW3B/3VP/E659U1m780b89HiQ9M3E/zY4rKICupXb/8FaU= X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jun 2016 11:36:59.3442 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0801MB1737 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Should print on success: [root@localhost ~]# ./test_mremap_vdso_32 AT_SYSINFO_EHDR is 0xf773f000 [NOTE] Moving vDSO: [f773f000, f7740000] -> [a000000, a001000] [OK] Or print that mremap for vDSO is unsupported: [root@localhost ~]# ./test_mremap_vdso_32 AT_SYSINFO_EHDR is 0xf773c000 [NOTE] Moving vDSO: [0xf773c000, 0xf773d000] -> [0xf7737000, 0xf7738000] [FAIL] mremap() of the vDSO does not work on this kernel! Cc: Andy Lutomirski Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: Shuah Khan Cc: x86@kernel.org Cc: linux-kselftest@vger.kernel.org Suggested-by: Andy Lutomirski Signed-off-by: Dmitry Safonov --- tools/testing/selftests/x86/Makefile | 3 +- tools/testing/selftests/x86/test_mremap_vdso.c | 111 +++++++++++++++++++++++++ 2 files changed, 113 insertions(+), 1 deletion(-) create mode 100644 tools/testing/selftests/x86/test_mremap_vdso.c diff --git a/tools/testing/selftests/x86/Makefile b/tools/testing/selftests/x86/Makefile index abe9c35c1cb6..c701349d4920 100644 --- a/tools/testing/selftests/x86/Makefile +++ b/tools/testing/selftests/x86/Makefile @@ -5,7 +5,8 @@ include ../lib.mk .PHONY: all all_32 all_64 warn_32bit_failure clean TARGETS_C_BOTHBITS := single_step_syscall sysret_ss_attrs syscall_nt ptrace_syscall \ - check_initial_reg_state sigreturn ldt_gdt iopl mpx-mini-test + check_initial_reg_state sigreturn ldt_gdt iopl mpx-mini-test \ + test_mremap_vdso TARGETS_C_32BIT_ONLY := entry_from_vm86 syscall_arg_fault test_syscall_vdso unwind_vdso \ test_FCMOV test_FCOMI test_FISTTP \ vdso_restorer diff --git a/tools/testing/selftests/x86/test_mremap_vdso.c b/tools/testing/selftests/x86/test_mremap_vdso.c new file mode 100644 index 000000000000..a489a2410664 --- /dev/null +++ b/tools/testing/selftests/x86/test_mremap_vdso.c @@ -0,0 +1,111 @@ +/* + * 32-bit test to check vdso mremap. + * + * Copyright (c) 2016 Dmitry Safonov + * Suggested-by: Andrew Lutomirski + * + * This program is free software; you can redistribute it and/or modify + * it under the terms and conditions of the GNU General Public License, + * version 2, as published by the Free Software Foundation. + * + * This program is distributed in the hope it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + */ +/* + * Can be built statically: + * gcc -Os -Wall -static -m32 test_mremap_vdso.c + */ +#define _GNU_SOURCE +#include +#include +#include +#include + +#include +#include +#include +#include + +#define PAGE_SIZE 4096 + +static int try_to_remap(void *vdso_addr, unsigned long size) +{ + void *dest_addr, *new_addr; + + /* Searching for memory location where to remap */ + dest_addr = mmap(0, size, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0); + if (dest_addr == MAP_FAILED) { + printf("[WARN]\tmmap failed (%d): %m\n", errno); + return 0; + } + + printf("[NOTE]\tMoving vDSO: [%p, %#lx] -> [%p, %#lx]\n", + vdso_addr, (unsigned long)vdso_addr + size, + dest_addr, (unsigned long)dest_addr + size); + fflush(stdout); + + new_addr = mremap(vdso_addr, size, size, + MREMAP_FIXED|MREMAP_MAYMOVE, dest_addr); + if ((unsigned long)new_addr == (unsigned long)-1) { + munmap(dest_addr, size); + if (errno == EINVAL) { + printf("[NOTE]\tvDSO partial move failed, will try with bigger size\n"); + return -1; /* Retry with larger */ + } + printf("[FAIL]\tmremap failed (%d): %m\n", errno); + return 1; + } + + return 0; + +} + +int main(int argc, char **argv, char **envp) +{ + pid_t child; + + child = fork(); + if (child == -1) { + printf("[WARN]\tfailed to fork (%d): %m\n", errno); + return 1; + } + + if (child == 0) { + unsigned long vdso_size = PAGE_SIZE; + unsigned long auxval; + int ret = -1; + + auxval = getauxval(AT_SYSINFO_EHDR); + printf("\tAT_SYSINFO_EHDR is %#lx\n", auxval); + if (!auxval || auxval == -ENOENT) { + printf("[WARN]\tgetauxval failed\n"); + return 0; + } + + /* Simpler than parsing ELF header */ + while (ret < 0) { + ret = try_to_remap((void *)auxval, vdso_size); + vdso_size += PAGE_SIZE; + } + + /* Glibc is likely to explode now - exit with raw syscall */ + asm volatile ("int $0x80" : : "a" (__NR_exit), "b" (!!ret)); + } else { + int status; + + if (waitpid(child, &status, 0) != child || + !WIFEXITED(status)) { + printf("[FAIL]\tmremap() of the vDSO does not work on this kernel!\n"); + return 1; + } else if (WEXITSTATUS(status) != 0) { + printf("[FAIL]\tChild failed with %d\n", + WEXITSTATUS(status)); + return 1; + } + printf("[OK]\n"); + } + + return 0; +} -- 2.9.0 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752695AbcF1LjI (ORCPT ); Tue, 28 Jun 2016 07:39:08 -0400 Received: from mail-db3on0122.outbound.protection.outlook.com ([157.55.234.122]:21403 "EHLO emea01-db3-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752023AbcF1LhA (ORCPT ); Tue, 28 Jun 2016 07:37:00 -0400 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=dsafonov@virtuozzo.com; From: Dmitry Safonov To: CC: <0x7f454c46@gmail.com>, , , , Dmitry Safonov Subject: [PATCHv10 0/2] mremap vDSO for 32-bit Date: Tue, 28 Jun 2016 14:35:37 +0300 Message-ID: <20160628113539.13606-1-dsafonov@virtuozzo.com> X-Mailer: git-send-email 2.9.0 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [195.214.232.10] X-ClientProxiedBy: AMSPR02CA0032.eurprd02.prod.outlook.com (10.242.225.160) To HE1PR0801MB1737.eurprd08.prod.outlook.com (10.168.149.149) X-MS-Office365-Filtering-Correlation-Id: ab8f7e56-e0ae-489a-c3be-08d39f4882fa X-Microsoft-Exchange-Diagnostics: 1;HE1PR0801MB1737;2:q0FTVwO3P/rgnXjt9Axwed6D4CpJv4raqghvzmL8A+z1KWC11nFaB9NllpPpKaIMdHgHaR6bGBv18epOaqyPykniifxQFWfgJIQ1Hz5uF0gcG/XrVfs1fdajlJxKiuaFjULpT4cn59oSH6YN+eNwuA0AkV0TjJvzExmb+o+j9sDKXaBgkjuU6O0l0WYJE4Tx;3:t0F0sj6qU+UtdALDmmJvbW+sdxuGCQqxrtsdhBDjN8C5HHyl+GDqJ4ILiNDGQJ/xVjy/3BApljJYHBaKb4LBb/F4LntM4H0Ovf2aKcY0ZUmpSjsIq0ylGHswhv6AJmL4;25:jFiI566IKd/u7vct08djksHBePLFQsS3cv7WrdXni0rMr2buv7MeR0THsve4y9tPF7WknUojD1H9VSKYndX9ve04SWfMgSN+688kVqxvLjkjk3yTq9oog6irFf9leyfA9gfinZ4VFfaekFUpfFQuHMN/Ag8LvD+v9wqcWzvBz+KxqG86R9bN5jrNUJJlmU1FzmnkcZfp7KOj3TQkZAD9c4WJBwm6W7tN0Tw8a6i6BSI2hR64ejHJetUbizzHWdTVNt4QFS9fT4j0zNxtka60uRVkrZTJpW+t9ekKKMP4Jz+HMvgw8jfn41Io7f8FIcaszuP6zU3jeKPbLLtUE5YPQDwj6ul8SZ+B16wbs9dA03JZ2ivW3UZGTb4hFS0eu0Q259pZAj6fPrD2Su2Ap9TqEuyZtUNQRP0m2aIiXkwpU5E= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0801MB1737; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(278428928389397); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040130)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041072)(6043046);SRVR:HE1PR0801MB1737;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0801MB1737; X-Microsoft-Exchange-Diagnostics: 1;HE1PR0801MB1737;4:taYo5ribeKJTpQFBSAktxM+dWkRCrnA6OViLliRejaGsEOeANP0/5BRw60AZZHYJcIL8n2Mn276x0dXc7hPD06+VDABX+295a03trEnfwzM+2wL8AyhUDfPzK87PEBYPrAmzS4DEeZn4nuEOBQnukhIiEz2H0ZSBQyajRAsYDFgNpRtd4S2YhV8nrufLFy9shb8BKDL9KM1IEpo73HrACH6T1JPgQJMv9uEo729L8t57esIvikcqjbhpamuw88dT2XL32jf0AI2bOz7pxvzvB+68CeX5F4nAdW0M4uXZqHiVJj+1ivJZH43lxQi4HpiHgMVqQ7ETkOwM/SR6SMrWsdMNIQcb/CsBagpgG4lKDsEFSr1rW/btRiG4K5QsqZznILta8SMYdE9ZmFjN2SzE87Bs/uBdRK6QHnI1K8fgkUGjritYECQf5jgJkYBc2o7qiP9RDBw4f86OWMiur6Mva4Ce8ztObtbhX9EA3LqIMwI= X-Forefront-PRVS: 0987ACA2E2 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(4630300001)(6009001)(7916002)(54534003)(199003)(189002)(3846002)(105586002)(586003)(92566002)(53416004)(6116002)(5003940100001)(69596002)(4001430100002)(19580395003)(7736002)(305945005)(81156014)(77096005)(81166006)(106356001)(8676002)(66066001)(47776003)(42186005)(1076002)(68736007)(33646002)(7846002)(50466002)(97736004)(50226002)(229853001)(2906002)(101416001)(2351001)(107886002)(110136002)(48376002)(4326007)(36756003)(189998001)(86362001)(50986999);DIR:OUT;SFP:1102;SCL:1;SRVR:HE1PR0801MB1737;H:dsafonov.sw.ru;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;HE1PR0801MB1737;23:X2x23jwkkHbpcGNNUCyN3pzpjhf96xKO9cB4GDY?= =?us-ascii?Q?3MNyTV9weRq8c8W8n/dDRmAIERPryPtd2jhwK7E46386mA++f10Le8wEI83a?= =?us-ascii?Q?dGUKsWK7XenM42OlS29GjYMphqR1nepvBQtLzMUgOMomSOjuYCT8ECrRBs1U?= =?us-ascii?Q?6xpWs5fN+Sk7vPr1tnds0DUGFb/k7UbZtNrnkNk2/FShm3UsR6tpAJt43WjQ?= =?us-ascii?Q?IO8zP3+JV6fis1yrdMe9DrbnOORaaCKIltQOyYffqYtTuA08mD0emmAIIt8B?= =?us-ascii?Q?rIi/ap8jfa7qBseJzWevGk3aMABfhT6H6F8Rezn9BbIpGpNYw+l8pyOUr9iB?= =?us-ascii?Q?91HExTiXqFy1GfA+aF8vTFMG0OHg28tfX+y+VJlQq2+ZOTOTLLYNt9vi8Jpd?= =?us-ascii?Q?k0zKwfC/kt7pS9EtO4zX1/P1r2NdgoY6DGbNIczv3LroYYQRYPNkjLBKNVz7?= =?us-ascii?Q?vuXTpWtMPTrCJxdv0tnPF0Ck7vj8AltuUWVGBfddiGnSOVYcuPO3Pw5odbZs?= =?us-ascii?Q?vIN4DqRUfKkkY5vYv8Ywxk5ElUVllVyRQEuDJjefoN58MKAjrhnEjNRgTvXc?= =?us-ascii?Q?Nt9gme/LcH/nQjE+dc7ibSHqTXerZrCLhlOBD954tC+q5xusEZ5L+QQdX4pl?= =?us-ascii?Q?lWTYDQaKxJUBIIJ5cHMpw5O/vnlxerfRr2qY3gkAjkOxTLDhxbgiyKfL9OKH?= =?us-ascii?Q?qRKKwByoQH2l54yj21hJ/AWzZKUNcCipj/dL2uj4jjINZOaELMcP6bHVryb3?= =?us-ascii?Q?CT060kbefrDb6qZyuNyZ37o7uNM94FbRfhOu/nHOIB99gFJTG4FnyIV1X9GN?= =?us-ascii?Q?5y+rMGWCh8KeCItWSVLNdkeEZRptYCyHQ2AZSubN0Ba/xMlcO6JWag84lvPf?= =?us-ascii?Q?NFrRgITtBT+RWXSmZFe5A3JIZSCXfevqXgFa1zEsDsUWBMTq41aHPZYFprPx?= =?us-ascii?Q?yzeRJKFRqBCk4HIM5pGLLblYmh4NoU2qiQ6FeBu58f6vwifFD9E+M9ZinHBJ?= =?us-ascii?Q?xYgK9KDF/cI2Fvc17gVkL3jo8WoCg+LpRBc7i9rDovU9HMGlhx0ZPjIYhSd8?= =?us-ascii?Q?cyx4ybV+UCydeaAmzoCT79SZYKyiLWiOfbB9FJdszn5R4jTtN+NQQz5EVFa4?= =?us-ascii?Q?cb6IvSj6hg1nvKSf5Bh9T/KJ5mPZ1lL/L?= X-Microsoft-Exchange-Diagnostics: 1;HE1PR0801MB1737;6:Xx+1+bidzwvcfTmGq21NknuiiUt+4FsKiGQykstARP54h+DydsSmT8Sv9H9z7xvmra45Op1gL2ABVBt0wI2B9zoxOVHDs9tFq1jFgwt1Ful6Zn4TKKKGOgs5vi6HMR6TvyO1AHpElHw8UftXC/V9BTB8SCpa+DwvcMcK5ID7JYd+EHZYwYKFdcfgh6zECh0qq+EbDS7rOICPNKI1OwjX4RU/6tXKM1udhIFe0sB2h4nFCH0KfkQsjE8Ty7euImytauk0fCxtcWoGyBqFGKc+LrfFXuFp3ZYyFXwQT8gvv944Wdl3ViPn5RC2fdKLOtOj5mfAg1lvyYcG5y+0WWf9OQ==;5:nOjbj3Trig7YDLEM2RjSdGinZsoaL9QDNM1r4y98or3RnCQeTvH5Cgu8veSmRswTP+cnP5UQQ8z8X7J/U9O8WPXh8NHNQxRVg0t/GmjH6J6urtUj+EWaz3nF8KD/fU63DZqU6vdigeKgMfoFdyON3w==;24:3CWd0GvbOJsT6aVCym0bRLk11bhobZeUFHR/RSzi3kIVgXidOgnwb83yykbkEPaIHrK+Guecv0cM7bg6K1gYTglH1a/DcXmy6IwaIEwUrR4=;7:k1zQ8TczaCCNVx1BOnLIhgFg5eGDwPyl7hCZzEZimGKlIiklaTKuu0Bb4WmyZSgher7FPd9tAdyXTEDGMOu0WnV9v80z/BhKKWsMNsHQyXAf4CBknaz3kZfG6B0k1wDNFp4S4O6AJ8ANy8uNSpOD4aEjKkS2OAQ2+9vQ+3YEQZTxJhdzIxyXo4HSucLFcI8Wkm19FOAqvEYPdFNmurvp7YbNGOFHfr62/A4G8fn+ejjL+sjD4o/KAZ09tLcAM26R/b5Fklw2xbK+k6Km+dHCRg== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;HE1PR0801MB1737;20:3E+blmxWpdHXeLzr2cLYOdNEb6Lsbbj7mjuxbMknt6x1XOpvV1mSgp1hrH0qgwPUtrawmgRPEU7dXTTsM9ZX4keFxkQoK9fFLzMFSegARrmVnOsogyjmfGY7i7BZxHHkIF0O7CiC6Cal+dwjNQPD1RcbRUXgd+YJPiMHaE3PwDw= X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jun 2016 11:36:56.4328 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0801MB1737 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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: v10: run selftest after fork() and treat child segfaults for a nice error reports. 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 | 3 +- tools/testing/selftests/x86/test_mremap_vdso.c | 111 +++++++++++++++++++++++++ 5 files changed, 168 insertions(+), 6 deletions(-) create mode 100644 tools/testing/selftests/x86/test_mremap_vdso.c -- 2.9.0 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755050AbcGFOEc (ORCPT ); Wed, 6 Jul 2016 10:04:32 -0400 Received: from mail-vk0-f54.google.com ([209.85.213.54]:35288 "EHLO mail-vk0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754173AbcGFOEa (ORCPT ); Wed, 6 Jul 2016 10:04:30 -0400 MIME-Version: 1.0 In-Reply-To: <20160628113539.13606-2-dsafonov@virtuozzo.com> References: <20160628113539.13606-1-dsafonov@virtuozzo.com> <20160628113539.13606-2-dsafonov@virtuozzo.com> From: Andy Lutomirski Date: Wed, 6 Jul 2016 07:03:48 -0700 Message-ID: Subject: Re: [PATCHv10 1/2] x86/vdso: add mremap hook to vm_special_mapping To: Dmitry Safonov Cc: "linux-kernel@vger.kernel.org" , Dmitry Safonov <0x7f454c46@gmail.com>, Ingo Molnar , Andrew Lutomirski , "linux-mm@kvack.org" , Thomas Gleixner , "H. Peter Anvin" , X86 ML Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 28, 2016 at 4:35 AM, Dmitry Safonov wrote: > 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 Acked-by: Andy Lutomirski From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754914AbcGHMRL (ORCPT ); Fri, 8 Jul 2016 08:17:11 -0400 Received: from mail-qt0-f195.google.com ([209.85.216.195]:35121 "EHLO mail-qt0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754155AbcGHMRI (ORCPT ); Fri, 8 Jul 2016 08:17:08 -0400 Date: Fri, 8 Jul 2016 14:17:04 +0200 From: Ingo Molnar To: Dmitry Safonov Cc: linux-kernel@vger.kernel.org, 0x7f454c46@gmail.com, mingo@redhat.com, luto@kernel.org, linux-mm@kvack.org, Thomas Gleixner , "H. Peter Anvin" , Shuah Khan , x86@kernel.org, linux-kselftest@vger.kernel.org Subject: Re: [PATCHv10 2/2] selftest/x86: add mremap vdso test Message-ID: <20160708121704.GA31371@gmail.com> References: <20160628113539.13606-1-dsafonov@virtuozzo.com> <20160628113539.13606-3-dsafonov@virtuozzo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160628113539.13606-3-dsafonov@virtuozzo.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Dmitry Safonov wrote: > Or print that mremap for vDSO is unsupported: > [root@localhost ~]# ./test_mremap_vdso_32 > AT_SYSINFO_EHDR is 0xf773c000 > [NOTE] Moving vDSO: [0xf773c000, 0xf773d000] -> [0xf7737000, 0xf7738000] > [FAIL] mremap() of the vDSO does not work on this kernel! Hm, I tried this on a 64-bit kernel and got: triton:~/tip/tools/testing/selftests/x86> ./test_mremap_vdso_32 AT_SYSINFO_EHDR is 0xf7773000 [NOTE] Moving vDSO: [0xf7773000, 0xf7774000] -> [0xf776e000, 0xf776f000] Segmentation fault Thanks, Ingo From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755357AbcGHNRC (ORCPT ); Fri, 8 Jul 2016 09:17:02 -0400 Received: from terminus.zytor.com ([198.137.202.10]:53974 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754947AbcGHNQz (ORCPT ); Fri, 8 Jul 2016 09:16:55 -0400 Date: Fri, 8 Jul 2016 06:16:00 -0700 From: tip-bot for Dmitry Safonov Message-ID: Cc: jpoimboe@redhat.com, dvlasenk@redhat.com, hpa@zytor.com, torvalds@linux-foundation.org, dsafonov@virtuozzo.com, bp@alien8.de, brgerst@gmail.com, linux-kernel@vger.kernel.org, luto@kernel.org, peterz@infradead.org, tglx@linutronix.de, mingo@kernel.org Reply-To: jpoimboe@redhat.com, dvlasenk@redhat.com, linux-kernel@vger.kernel.org, torvalds@linux-foundation.org, dsafonov@virtuozzo.com, hpa@zytor.com, bp@alien8.de, brgerst@gmail.com, tglx@linutronix.de, luto@kernel.org, peterz@infradead.org, mingo@kernel.org In-Reply-To: <20160628113539.13606-2-dsafonov@virtuozzo.com> References: <20160628113539.13606-2-dsafonov@virtuozzo.com> To: linux-tip-commits@vger.kernel.org Subject: [tip:x86/mm] x86/vdso: Add mremap hook to vm_special_mapping Git-Commit-ID: b059a453b1cf1c8453c2b2ed373d3147d6264ebd X-Mailer: tip-git-log-daemon Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Commit-ID: b059a453b1cf1c8453c2b2ed373d3147d6264ebd Gitweb: http://git.kernel.org/tip/b059a453b1cf1c8453c2b2ed373d3147d6264ebd Author: Dmitry Safonov AuthorDate: Tue, 28 Jun 2016 14:35:38 +0300 Committer: Ingo Molnar CommitDate: Fri, 8 Jul 2016 14:17:51 +0200 x86/vdso: Add mremap hook to vm_special_mapping Add possibility for 32-bit user-space applications to move the vDSO mapping. Previously, when a user-space app called mremap() for the vDSO address, in the syscall return path it would land on the previous address of the vDSOpage, resulting in segmentation violation. Now it lands fine and returns to userspace with a remapped vDSO. This will also fix the context.vdso pointer for 64-bit, which does not affect the user of vDSO after mremap() currently, but this may change in the future. As suggested by Andy, return -EINVAL for mremap() that would split the vDSO image: that operation cannot possibly result in a working system so reject it. Renamed and moved the text_mapping structure declaration inside map_vdso(), as it used only there and now it complements the vvar_mapping variable. There is still a problem for remapping the vDSO in glibc applications: the linker relocates addresses for syscalls on the vDSO page, so you need to relink with the new addresses. Without that 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 Acked-by: Andy Lutomirski Cc: 0x7f454c46@gmail.com Cc: Borislav Petkov Cc: Brian Gerst Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Josh Poimboeuf Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/20160628113539.13606-2-dsafonov@virtuozzo.com Signed-off-by: Ingo Molnar --- 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 ab220ac..3329844 100644 --- a/arch/x86/entry/vdso/vma.c +++ b/arch/x86/entry/vdso/vma.c @@ -12,6 +12,7 @@ #include #include #include +#include #include #include #include @@ -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 ca3e517..917f2b6 100644 --- a/include/linux/mm_types.h +++ b/include/linux/mm_types.h @@ -594,6 +594,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 de2c176..234edff 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, }; From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755409AbcGHNRl (ORCPT ); Fri, 8 Jul 2016 09:17:41 -0400 Received: from terminus.zytor.com ([198.137.202.10]:54020 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754985AbcGHNRc (ORCPT ); Fri, 8 Jul 2016 09:17:32 -0400 Date: Fri, 8 Jul 2016 06:16:31 -0700 From: tip-bot for Dmitry Safonov Message-ID: Cc: shuahkh@osg.samsung.com, hpa@zytor.com, dsafonov@virtuozzo.com, tglx@linutronix.de, mingo@kernel.org, torvalds@linux-foundation.org, dvlasenk@redhat.com, brgerst@gmail.com, bp@alien8.de, peterz@infradead.org, luto@kernel.org, jpoimboe@redhat.com, linux-kernel@vger.kernel.org Reply-To: dvlasenk@redhat.com, mingo@kernel.org, torvalds@linux-foundation.org, tglx@linutronix.de, shuahkh@osg.samsung.com, dsafonov@virtuozzo.com, hpa@zytor.com, linux-kernel@vger.kernel.org, bp@alien8.de, peterz@infradead.org, jpoimboe@redhat.com, luto@kernel.org, brgerst@gmail.com In-Reply-To: <20160628113539.13606-3-dsafonov@virtuozzo.com> References: <20160628113539.13606-3-dsafonov@virtuozzo.com> To: linux-tip-commits@vger.kernel.org Subject: [tip:x86/mm] selftests/x86: Add vDSO mremap() test Git-Commit-ID: f80fd3a5fff88a9ace7e8cd11d07cf874a63ea9f X-Mailer: tip-git-log-daemon Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Commit-ID: f80fd3a5fff88a9ace7e8cd11d07cf874a63ea9f Gitweb: http://git.kernel.org/tip/f80fd3a5fff88a9ace7e8cd11d07cf874a63ea9f Author: Dmitry Safonov AuthorDate: Tue, 28 Jun 2016 14:35:39 +0300 Committer: Ingo Molnar CommitDate: Fri, 8 Jul 2016 14:17:51 +0200 selftests/x86: Add vDSO mremap() test Should print this on vDSO remapping success (on new kernels): [root@localhost ~]# ./test_mremap_vdso_32 AT_SYSINFO_EHDR is 0xf773f000 [NOTE] Moving vDSO: [f773f000, f7740000] -> [a000000, a001000] [OK] Or print that mremap() for vDSOs is unsupported: [root@localhost ~]# ./test_mremap_vdso_32 AT_SYSINFO_EHDR is 0xf773c000 [NOTE] Moving vDSO: [0xf773c000, 0xf773d000] -> [0xf7737000, 0xf7738000] [FAIL] mremap() of the vDSO does not work on this kernel! Suggested-by: Andy Lutomirski Signed-off-by: Dmitry Safonov Acked-by: Andy Lutomirski Cc: 0x7f454c46@gmail.com Cc: Borislav Petkov Cc: Brian Gerst Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Josh Poimboeuf Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Shuah Khan Cc: Thomas Gleixner Cc: linux-kselftest@vger.kernel.org Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/20160628113539.13606-3-dsafonov@virtuozzo.com Signed-off-by: Ingo Molnar --- tools/testing/selftests/x86/Makefile | 2 +- tools/testing/selftests/x86/test_mremap_vdso.c | 111 +++++++++++++++++++++++++ 2 files changed, 112 insertions(+), 1 deletion(-) diff --git a/tools/testing/selftests/x86/Makefile b/tools/testing/selftests/x86/Makefile index c73425d..543a6d0 100644 --- a/tools/testing/selftests/x86/Makefile +++ b/tools/testing/selftests/x86/Makefile @@ -4,7 +4,7 @@ include ../lib.mk .PHONY: all all_32 all_64 warn_32bit_failure clean -TARGETS_C_BOTHBITS := single_step_syscall sysret_ss_attrs syscall_nt ptrace_syscall \ +TARGETS_C_BOTHBITS := single_step_syscall sysret_ss_attrs syscall_nt ptrace_syscall test_mremap_vdso \ check_initial_reg_state sigreturn ldt_gdt iopl TARGETS_C_32BIT_ONLY := entry_from_vm86 syscall_arg_fault test_syscall_vdso unwind_vdso \ test_FCMOV test_FCOMI test_FISTTP \ diff --git a/tools/testing/selftests/x86/test_mremap_vdso.c b/tools/testing/selftests/x86/test_mremap_vdso.c new file mode 100644 index 0000000..bf0d687 --- /dev/null +++ b/tools/testing/selftests/x86/test_mremap_vdso.c @@ -0,0 +1,111 @@ +/* + * 32-bit test to check vDSO mremap. + * + * Copyright (c) 2016 Dmitry Safonov + * Suggested-by: Andrew Lutomirski + * + * This program is free software; you can redistribute it and/or modify + * it under the terms and conditions of the GNU General Public License, + * version 2, as published by the Free Software Foundation. + * + * This program is distributed in the hope it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + */ +/* + * Can be built statically: + * gcc -Os -Wall -static -m32 test_mremap_vdso.c + */ +#define _GNU_SOURCE +#include +#include +#include +#include + +#include +#include +#include +#include + +#define PAGE_SIZE 4096 + +static int try_to_remap(void *vdso_addr, unsigned long size) +{ + void *dest_addr, *new_addr; + + /* Searching for memory location where to remap */ + dest_addr = mmap(0, size, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0); + if (dest_addr == MAP_FAILED) { + printf("[WARN]\tmmap failed (%d): %m\n", errno); + return 0; + } + + printf("[NOTE]\tMoving vDSO: [%p, %#lx] -> [%p, %#lx]\n", + vdso_addr, (unsigned long)vdso_addr + size, + dest_addr, (unsigned long)dest_addr + size); + fflush(stdout); + + new_addr = mremap(vdso_addr, size, size, + MREMAP_FIXED|MREMAP_MAYMOVE, dest_addr); + if ((unsigned long)new_addr == (unsigned long)-1) { + munmap(dest_addr, size); + if (errno == EINVAL) { + printf("[NOTE]\tvDSO partial move failed, will try with bigger size\n"); + return -1; /* Retry with larger */ + } + printf("[FAIL]\tmremap failed (%d): %m\n", errno); + return 1; + } + + return 0; + +} + +int main(int argc, char **argv, char **envp) +{ + pid_t child; + + child = fork(); + if (child == -1) { + printf("[WARN]\tfailed to fork (%d): %m\n", errno); + return 1; + } + + if (child == 0) { + unsigned long vdso_size = PAGE_SIZE; + unsigned long auxval; + int ret = -1; + + auxval = getauxval(AT_SYSINFO_EHDR); + printf("\tAT_SYSINFO_EHDR is %#lx\n", auxval); + if (!auxval || auxval == -ENOENT) { + printf("[WARN]\tgetauxval failed\n"); + return 0; + } + + /* Simpler than parsing ELF header */ + while (ret < 0) { + ret = try_to_remap((void *)auxval, vdso_size); + vdso_size += PAGE_SIZE; + } + + /* Glibc is likely to explode now - exit with raw syscall */ + asm volatile ("int $0x80" : : "a" (__NR_exit), "b" (!!ret)); + } else { + int status; + + if (waitpid(child, &status, 0) != child || + !WIFEXITED(status)) { + printf("[FAIL]\tmremap() of the vDSO does not work on this kernel!\n"); + return 1; + } else if (WEXITSTATUS(status) != 0) { + printf("[FAIL]\tChild failed with %d\n", + WEXITSTATUS(status)); + return 1; + } + printf("[OK]\n"); + } + + return 0; +}