[PATCH v7 8/9] ARM: vdso initialization, mapping, and synchronization

[Christopher Covington]

On 07/01/2014 10:17 AM, Andy Lutomirski wrote:
> On Tue, Jul 1, 2014 at 7:15 AM, Will Deacon <will.deacon at arm.com> wrote:
>> On Tue, Jul 01, 2014 at 03:11:04PM +0100, Nathan Lynch wrote:
>>> On 07/01/2014 04:03 AM, Will Deacon wrote:
>>>> On Mon, Jun 30, 2014 at 10:37:48PM +0100, Andy Lutomirski wrote:
>>>>> On 06/22/2014 08:11 PM, Nathan Lynch wrote:
>>>>>> Initialize the vdso page list at boot, install the vdso mapping at
>>>>>> exec time, and update the data page during timer ticks.  This code is
>>>>>> not built if CONFIG_VDSO is not enabled.
>>>>>>
>>>>>> Account for the vdso length when randomizing the offset from the
>>>>>> stack.  The vdso is placed immediately following the sigpage with a
>>>>>> separate install_special_mapping call in arm_install_vdso.
>>>>
>>>> [...]
>>>>
>>>>>> +/* assumes mmap_sem is write-locked */
>>>>>> +void arm_install_vdso(struct mm_struct *mm, unsigned long addr)
>>>>>> +{
>>>>>> + int ret;
>>>>>> +
>>>>>> + mm->context.vdso = ~0UL;
>>>>>> +
>>>>>> + if (vdso_pagelist == NULL)
>>>>>> +         return;
>>>>>> +
>>>>>> + /*
>>>>>> +  * Put vDSO base into mm struct before calling
>>>>>> +  * install_special_mapping so the perf counter mmap tracking
>>>>>> +  * code will recognise it as a vDSO.
>>>>>> +  */
>>>>>> + mm->context.vdso = addr;
>>>>>> +
>>>>>> + ret = install_special_mapping(mm, addr, vdso_mapping_len,
>>>>>> +                               VM_READ|VM_EXEC|
>>>>>> +                               VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
>>>>>> +                               vdso_pagelist);
>>>>>
>>>>> Eek.  You're mapping the shared data VM_MAYWRITE.  This will cause
>>>>> bizarre and confusing failures if ptrace pokes at it.
>>>>
>>>> Hmm, but how else can we support software breakpoints on the vdso?
>>>
>>> I believe Andy is suggesting separate VMAs (with different VM flags) for
>>> the VDSO's data and code.  So, breakpoints in code would work, but
>>> attempts to modify the data page via ptrace() would fail outright
>>> instead of silently COWing.
>>
>> Ah, yes. That makes a lot of sense for the data page -- we should do
>> something similar on arm64 too, since the CoW will break everything for the
>> task being debugged. We could also drop the EXEC flags too.
> 
> If you do this, I have a slight preference for the new vma being
> called "[vvar]" to match x86.  It'll make the CRIU people happy if and
> when they port it to ARM.

CRIU is functional on AArch32 and AArch64. I use norandmaps and identical
kernels so I've not needed explicit VDSO support (on A64), but it'd certainly
be nice for whoever does need it for things to be as much the same as
possible. Here is some description of it:

http://git.criu.org/?p=criu.git;a=commit;h=fe7b8aeb8c65e11e190282aae8db2d2bebd4f6e9

Christopher

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.