public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Nathan Lynch <Nathan_Lynch@mentor.com>
To: <x86@kernel.org>
Cc: Kees Cook <keescook@google.com>, <luto@amacapital.net>,
	<linux-kernel@vger.kernel.org>
Subject: randomized placement of x86_64 vdso
Date: Mon, 21 Apr 2014 11:52:42 -0500	[thread overview]
Message-ID: <53554CDA.1060806@mentor.com> (raw)

Hi x86/vdso people,

I've been working on adding a vDSO to 32-bit ARM, and Kees suggested I
look at x86_64's algorithm for placing the vDSO at a randomized offset
above the stack VMA.  I found that when the stack top occupies the
last slot in the PTE (is that the right term?), the vdso_addr routine
returns an address below mm->start_stack, equivalent to
(mm->start_stack & PAGE_MASK).  For instance if mm->start_stack is
0x7fff3ffffc96, vdso_addr returns 0x7fff3ffff000.

Since the address returned is always already occupied by the stack,
get_unmapped_area detects the collision and falls back to
vm_unmapped_area.  This results in the vdso being placed in the
address space next to libraries etc.  While this is generally
unnoticeable and doesn't break anything, it does mean that the vdso is
placed below the stack when there is actually room above the stack.
To me it also seems uncomfortably close to placing the vdso in the way
of downward expansion of the stack.

I don't have a patch because I'm not sure what the algorithm should
be, but thought I would bring it up as vdso_addr doesn't seem to be
behaving as intended in all cases.


Thanks,
Nathan

             reply	other threads:[~2014-04-21 16:52 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-21 16:52 Nathan Lynch [this message]
2014-04-23 16:30 ` randomized placement of x86_64 vdso H. Peter Anvin
2014-04-23 17:06   ` Nathan Lynch
2014-04-30 17:47     ` Kees Cook
2014-04-30 17:52       ` Andy Lutomirski
2014-04-30 18:13         ` Kees Cook
2014-04-30 18:30           ` Andy Lutomirski
2014-04-30 20:05             ` Kees Cook
2014-04-30 20:14               ` Andy Lutomirski

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=53554CDA.1060806@mentor.com \
    --to=nathan_lynch@mentor.com \
    --cc=keescook@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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