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]
Message-ID: <e1637788-6060-cbe4-1411-ccdb42ba38b8@virtuozzo.com>
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?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ