linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andy Lutomirski <luto@amacapital.net>
To: Dmitry Safonov <dsafonov@virtuozzo.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	X86 ML <x86@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	Dmitry Safonov <0x7f454c46@gmail.com>
Subject: Re: [PATCHv2] x86/vdso: add mremap hook to vm_special_mapping
Date: Thu, 14 Apr 2016 15:58:55 -0700	[thread overview]
Message-ID: <CALCETrUhDvdyJV53Am2sgefyMJmHs5u1voOM2N76Si7BTtJWaQ@mail.gmail.com> (raw)
In-Reply-To: <1460651571-10545-1-git-send-email-dsafonov@virtuozzo.com>

On Thu, Apr 14, 2016 at 9:32 AM, Dmitry Safonov <dsafonov@virtuozzo.com> 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.
>
> 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 32-bit glibc applications:
> linker relocates addresses for syscalls on vdso page, so
> you need to relink with the new addresses. Or the next syscall
> through glibc may fail:
>   Program received signal SIGSEGV, Segmentation fault.
>   #0  0xf7fd9b80 in __kernel_vsyscall ()
>   #1  0xf7ec8238 in _exit () from /usr/lib32/libc.so.6
>
> Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
> ---
> v2: added __maybe_unused for pt_regs in vdso_mremap
>
>  arch/x86/entry/vdso/vma.c | 33 ++++++++++++++++++++++++++++-----
>  include/linux/mm_types.h  |  3 +++
>  mm/mmap.c                 | 10 ++++++++++
>  3 files changed, 41 insertions(+), 5 deletions(-)
>
> diff --git a/arch/x86/entry/vdso/vma.c b/arch/x86/entry/vdso/vma.c
> index 10f704584922..7e261e2554c8 100644
> --- a/arch/x86/entry/vdso/vma.c
> +++ b/arch/x86/entry/vdso/vma.c
> @@ -12,6 +12,7 @@
>  #include <linux/random.h>
>  #include <linux/elf.h>
>  #include <linux/cpu.h>
> +#include <linux/ptrace.h>
>  #include <asm/pvclock.h>
>  #include <asm/vgtod.h>
>  #include <asm/proto.h>
> @@ -98,10 +99,26 @@ 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 int vdso_mremap(const struct vm_special_mapping *sm,
> +                     struct vm_area_struct *new_vma)
> +{
> +       struct pt_regs __maybe_unused *regs = current_pt_regs();
> +
> +#if defined(CONFIG_X86_32) || defined(CONFIG_IA32_EMULATION)
> +       /* Fixing userspace landing - look at do_fast_syscall_32 */
> +       if (regs->ip == (unsigned long)current->mm->context.vdso +
> +                       vdso_image_32.sym_int80_landing_pad
> +#ifdef CONFIG_IA32_EMULATION
> +               && current_thread_info()->status & TS_COMPAT
> +#endif

Instead of ifdef, use the (grossly misnamed) is_ia32_task() helper for
this, please.

> +          )
> +               regs->ip = new_vma->vm_start +
> +                       vdso_image_32.sym_int80_landing_pad;
> +#endif
> +       new_vma->vm_mm->context.vdso = (void __user *)new_vma->vm_start;

Can you arrange for the mremap call to fail if the old mapping gets
split?  This might be as simple as confirming that the new mapping's
length is what we expect it to be and, if it isn't, returning -EINVAL.

If anyone things that might break some existing application (which is
quite unlikely), then we could allow mremap to succeed but skip the
part where we change context.vdso and rip.

> +
> +       return 0;
> +}
>
>  static int vvar_fault(const struct vm_special_mapping *sm,
>                       struct vm_area_struct *vma, struct vm_fault *vmf)
> @@ -162,6 +179,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,
> +       };

Why did you add this instead of modifying text_mapping?

--Andy

  reply	other threads:[~2016-04-14 22:59 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-11 15:22 [PATCH] x86/vdso: add mremap hook to vm_special_mapping Dmitry Safonov
2016-04-11 15:41 ` kbuild test robot
2016-04-11 15:54   ` Dmitry Safonov
2016-04-14 16:32 ` [PATCHv2] " Dmitry Safonov
2016-04-14 22:58   ` Andy Lutomirski [this message]
2016-04-15  8:46     ` Dmitry Safonov
2016-04-15  9:18     ` Ingo Molnar
2016-04-15  9:51       ` Dmitry Safonov
2016-04-15 12:08         ` Dmitry Safonov
2016-04-15 13:20 ` [PATCHv3 1/2] " Dmitry Safonov
2016-04-15 13:20   ` [PATCHv3 2/2] x86: rename is_{ia32,x32}_task to in_{ia32,x32}_syscall Dmitry Safonov
2016-04-15 16:52     ` Andy Lutomirski
2016-04-15 16:55       ` Dmitry Safonov
2016-04-15 13:53   ` [PATCHv3 1/2] x86/vdso: add mremap hook to vm_special_mapping kbuild test robot
2016-04-15 14:12 ` [PATCHv4 " Dmitry Safonov
2016-04-15 14:12   ` [PATCHv4 2/2] x86: rename is_{ia32,x32}_task to in_{ia32,x32}_syscall Dmitry Safonov
2016-04-15 16:58   ` [PATCHv4 1/2] x86/vdso: add mremap hook to vm_special_mapping Andy Lutomirski
2016-04-18 11:18     ` Dmitry Safonov
2016-04-18 15:37       ` Andy Lutomirski
2016-04-18 13:43 ` [PATCHv5 1/3] x86: rename is_{ia32,x32}_task to in_{ia32,x32}_syscall Dmitry Safonov
2016-04-18 13:43   ` [PATCHv5 2/3] x86/vdso: add mremap hook to vm_special_mapping Dmitry Safonov
2016-04-18 14:03     ` kbuild test robot
2016-04-18 14:17     ` [PATCHv6 " Dmitry Safonov
2016-04-18 14:23     ` [PATCHv7 " Dmitry Safonov
2016-04-20 16:22       ` Dmitry Safonov
2016-04-21 19:52       ` Andy Lutomirski
2016-04-22 10:45         ` Dmitry Safonov
2016-04-23 23:09     ` [PATCHv5 " kbuild test robot
2016-04-18 13:43   ` [PATCHv5 3/3] selftest/x86: add mremap vdso 32-bit test Dmitry Safonov
2016-04-21 20:01     ` Andy Lutomirski
2016-04-22 11:34       ` Dmitry Safonov
2016-04-19  9:34   ` [tip:x86/asm] x86/entry: Rename is_{ia32,x32}_task() to in_{ia32,x32}_syscall() tip-bot for Dmitry Safonov
2016-04-19 11:15     ` Ingo Molnar
2016-04-19 11:35       ` Borislav Petkov
2016-04-19 17:00         ` H. Peter Anvin
2016-04-19 16:04       ` Andy Lutomirski
2016-04-22  8:36         ` Ingo Molnar
2018-10-18  1:47     ` in_compat_syscall() returns from kernel thread for X86_32 NeilBrown
2018-10-18  2:37       ` Andy Lutomirski
2018-10-18  2:49         ` Al Viro
2018-10-18  4:36         ` NeilBrown
2018-10-18 17:26           ` Andy Lutomirski
2018-10-20  6:02             ` Andreas Dilger
2018-10-20  7:58               ` Andy Lutomirski
2018-10-24  1:47             ` NeilBrown
2018-10-24 13:15               ` Theodore Y. Ts'o
2018-10-24 14:32                 ` Theodore Y. Ts'o
2019-01-11 22:21                   ` Pavel Machek
2018-10-25  3:46                 ` NeilBrown
2018-10-25  4:45                   ` Andy Lutomirski
2016-04-25 11:37 ` [PATCHv8 1/2] x86/vdso: add mremap hook to vm_special_mapping Dmitry Safonov
2016-04-25 11:37   ` [PATCHv8 2/2] selftest/x86: add mremap vdso test Dmitry Safonov
2016-04-25 21:39     ` Andy Lutomirski
2016-04-25 21:38   ` [PATCHv8 1/2] x86/vdso: add mremap hook to vm_special_mapping Andy Lutomirski
     [not found]     ` <e0a10957-ddf7-1bc4-fad6-8b5836628fce@virtuozzo.com>
2016-05-05 11:52       ` Ingo Molnar
2016-05-05 11:55         ` Dmitry Safonov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CALCETrUhDvdyJV53Am2sgefyMJmHs5u1voOM2N76Si7BTtJWaQ@mail.gmail.com \
    --to=luto@amacapital.net \
    --cc=0x7f454c46@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=dsafonov@virtuozzo.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).