linux-kernel - Re: randomized placement of x86

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 30 Apr 2014 10:52:14 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Kees Cook <keescook@...gle.com>
Cc:	Nathan Lynch <Nathan_Lynch@...tor.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	"x86@...nel.org" <x86@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: randomized placement of x86_64 vdso

On Wed, Apr 30, 2014 at 10:47 AM, Kees Cook <keescook@...gle.com> wrote:
> On Wed, Apr 23, 2014 at 10:06 AM, Nathan Lynch <Nathan_Lynch@...tor.com> wrote:
>> On 04/23/2014 11:30 AM, H. Peter Anvin wrote:
>>> On 04/21/2014 09:52 AM, Nathan Lynch wrote:
>>>> 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.
>>>>
>>>
>>> If the stack occupies the last possible page, how can you say there is
>>> "space above the stack"?
>>
>> Sorry for being unclear.  I probably am getting terminology wrong.  What
>> I'm trying to express is that if the stack top is in the last page of
>> its last-level page table (which may be the last possible page, but
>> that's not really the interesting case), vdso_addr returns an address
>> below mm->start_stack.
>
> It seems like this is avoidable, then? From your example, it seems
> like we lose the separated randomization in this case, but we don't
> need to? Do you have a suggestion for what could be done to fix this?

I don't understand why the vDSO should be special here.  Either the
standard logic for randomizing the placement of DSOs is good, in which
case it should be good for the vDSO too, or I think we should fix it
for everything.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/