From mboxrd@z Thu Jan  1 00:00:00 1970
From: Nathan_Lynch@mentor.com (Nathan Lynch)
Date: Thu, 27 Mar 2014 19:20:28 -0500
Subject: [PATCH v5] ARM: vDSO gettimeofday using generic timer architecture
In-Reply-To: <CAGXu5jKojxJyhKSpPtLDT8Cw4wwUiKauoFUP5xuSJnKioDXGrQ@mail.gmail.com>
References: <1395695873-12807-1-git-send-email-nathan_lynch@mentor.com>
 <CAGXu5jKojxJyhKSpPtLDT8Cw4wwUiKauoFUP5xuSJnKioDXGrQ@mail.gmail.com>
Message-ID: <5334C04C.2050802@mentor.com>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org

On 03/27/2014 06:06 PM, Kees Cook wrote:
> On Mon, Mar 24, 2014 at 2:17 PM, Nathan Lynch <nathan_lynch@mentor.com> wrote:
>> +
>> +/* assumes mmap_sem is write-locked */
>> +void arm_install_vdso(struct mm_struct *mm)
>> +{
>> +       unsigned long vdso_base;
>> +       int ret;
>> +
>> +       mm->context.vdso = ~0UL;
>> +
>> +       if (vdso_pagelist == NULL)
>> +               return;
>> +
>> +       vdso_base = get_unmapped_area(NULL, 0, vdso_mapping_len, 0, 0);
> 
> While get_unmapped_area() should be returning an address that has been
> base-offset randomized, I notice that x86 actually moves its vdso to a
> random location near the stack instead (see vdso_addr() in
> arch/x86/vdso/vma.c), in theory to avoid a hole in memory and to
> separately randomize the vdso separately from heap and stack. I think
> a similar thing be a benefit on ARM too.

OK, I'll look into this.  Perhaps a similar treatment for the sigpage?

I notice on my systems (OMAP5 and i.MX6) that vdso, sigpage, and ld.so
are always mapped consecutively:

# grep -A2 vdso /proc/self/maps
b6f44000-b6f46000 r-xp 00000000 00:00 0          [vdso]
b6f46000-b6f47000 r-xp 00000000 00:00 0          [sigpage]
b6f47000-b6f48000 r--p 00016000 00:01 1254       /lib/ld-2.19.90.so

but I wonder if that's due to starved entropy pools, or is the VM
already trying to prevent holes?


>> +       if (IS_ERR_VALUE(vdso_base)) {
>> +               pr_notice_once("%s: get_unapped_area failed (%ld)\n",
>> +                              __func__, (long)vdso_base);
>> +               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 = vdso_base;
>> +
>> +       ret = install_special_mapping(mm, vdso_base, vdso_mapping_len,
>> +                                     VM_READ|VM_EXEC|
>> +                                     VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
>> +                                     vdso_pagelist);
> 
> Why is this given VM_MAYWRITE? (I would ask the same about x86's
> implementation too.)

For setting breakpoints in the text area.  FWIW powerpc's
arch_setup_additional_pages has this comment:

/*
 * our vma flags don't have VM_WRITE so by default, the process isn't
 * allowed to write those pages.
 * gdb can break that with ptrace interface, and thus trigger COW on
 * those pages but it's then your responsibility to never do that on
 * the "data" page of the vDSO or you'll stop getting kernel updates
 * and your nice userland gettimeofday will be totally dead.
 * It's fine to use that for setting breakpoints in the vDSO code
 * pages though.
 */
rc = install_special_mapping(mm, vdso_base, vdso_pages << PAGE_SHIFT,
			     VM_READ|VM_EXEC|
			     VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
			     vdso_pagelist);