On 26/03/2015 10:43, Ingo Molnar wrote:
>
> * Benjamin Herrenschmidt <b...@kernel.crashing.org> wrote:
>
>> On Wed, 2015-03-25 at 19:36 +0100, Ingo Molnar wrote:
>>> * Ingo Molnar <mi...@kernel.org> wrote:
>>>
>>>>> +#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.
>>>
>>> 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?
>>
>> 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 ...
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.
> 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...
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
User-mode-linux-user mailing list
User-mode-linux-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
