linux-kernel - Re: [PATCHv9 0/2] mremap vDSO for 32-bit

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 19 May 2016 12:50:20 +0300
From:	Dmitry Safonov <dsafonov@...tuozzo.com>
To:	<linux-kernel@...r.kernel.org>, <mingo@...hat.com>
CC:	<luto@...capital.net>, <tglx@...utronix.de>, <hpa@...or.com>,
	<x86@...nel.org>, <akpm@...ux-foundation.org>,
	<linux-mm@...ck.org>, <0x7f454c46@...il.com>
Subject: Re: [PATCHv9 0/2] mremap vDSO for 32-bit

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

Ping?