linux-kernel - Re: [x86, vdso] BUG: unable to handle kernel paging request at d34bd000

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:	Mon, 10 Mar 2014 10:31:14 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	"H. Peter Anvin" <hpa@...ux.intel.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Stefani Seibold <stefani@...bold.net>,
	Andreas Brief <Andreas.Brief@...de-schwarz.com>,
	Martin Runge <Martin.Runge@...de-schwarz.com>
Subject: Re: [x86, vdso] BUG: unable to handle kernel paging request at d34bd000

On Mon, Mar 10, 2014 at 10:24 AM, H. Peter Anvin <hpa@...ux.intel.com> wrote:
> On 03/10/2014 10:12 AM, Andy Lutomirski wrote:
>> On Mon, Mar 10, 2014 at 8:11 AM, Linus Torvalds
>> <torvalds@...ux-foundation.org> wrote:
>>>
>>> On Mar 10, 2014 8:01 AM, "H. Peter Anvin" <hpa@...ux.intel.com> wrote:
>>>>
>>>> I have mentioned in the past wanting to move the fixmap to the low part
>>>> of the kernel space, because the top isn't really fixed...
>>>
>>> How about the high part of the user address space, just above the stack?
>>> Leave a unmapped page in between, or something. The stack is already
>>> randomized, isn't it?
>>
>> For the !compat_vdso case, I don't like it -- this will put the vdso
>> (which is executable) at a constant offset from the stack, which will
>> make it much easier to use the vdso to defeat ASLR.
>>
>> For the compat_vdso case, this only works if the address is *not*
>> random, unless we're going to start giving each process its very own
>> relocated vdso.
>>
>
> I presumed we were talking about compat_vdso, which thus simply turns
> into a "don't randomize the vdso flag."  A significant side benefit is
> that this should make the code more similar.

Fair enough.  I still don't like having (top of stack - vdso) being
constant, but maybe that's avoidable.

>
>> For 64-bit, this is an entirely different story.  The vsyscall page is
>> stuck in the fixmap forever, although I want to add a way for
>> userspace to opt out.  The vvar page, hpet, etc could move into vmas,
>> though.  I kind of want to do that anyway to allow processes to turn
>> off the ability to read the clock.
>
> Wait... you want to do what?!

This isn't even my idea:

commit 8fb402bccf203ecca8f9e0202b8fd3c937dece6f
Author: Erik Bosman <ebn310@....vu.nl>
Date:   Fri Apr 11 18:54:17 2008 +0200

    generic, x86: add prctl commands PR_GET_TSC and PR_SET_TSC

    This patch adds prctl commands that make it possible
    to deny the execution of timestamp counters in userspace.
    If this is not implemented on a specific architecture,
    prctl will return -EINVAL.

Currently anything that tries to use the vdso will just crash if you
do that, and it fails to turn off direct HPET access.  Fixing this
might be nice, but the current vvar implementation makes it
impossible.  If you want to stick something in a seccomp sandbox and
make it very difficult for it to exploit timing side channels, then
this is important :)

--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/