From: Nathan_Lynch@mentor•com (Nathan Lynch)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH v5] ARM: vDSO gettimeofday using generic timer architecture
Date: Thu, 27 Mar 2014 19:20:28 -0500 [thread overview]
Message-ID: <5334C04C.2050802@mentor.com> (raw)
In-Reply-To: <CAGXu5jKojxJyhKSpPtLDT8Cw4wwUiKauoFUP5xuSJnKioDXGrQ@mail.gmail.com>
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);
next prev parent reply other threads:[~2014-03-28 0:20 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-24 21:17 [PATCH v5] ARM: vDSO gettimeofday using generic timer architecture Nathan Lynch
2014-03-27 23:06 ` Kees Cook
2014-03-28 0:20 ` Nathan Lynch [this message]
2014-03-28 18:42 ` Kees Cook
2014-03-29 12:18 ` Steve Capper
2014-04-10 20:59 ` Nathan Lynch
2014-04-14 22:05 ` Kees Cook
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5334C04C.2050802@mentor.com \
--to=nathan_lynch@mentor$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox