From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754555AbaCJUDh (ORCPT ); Mon, 10 Mar 2014 16:03:37 -0400 Received: from www84.your-server.de ([213.133.104.84]:43615 "EHLO www84.your-server.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753953AbaCJUDf (ORCPT ); Mon, 10 Mar 2014 16:03:35 -0400 Message-ID: <1394481804.980.9.camel@wall-e.seibold.net> Subject: Re: [x86, vdso] BUG: unable to handle kernel paging request at d34bd000 From: Stefani Seibold To: Andy Lutomirski Cc: Linus Torvalds , Peter Anvin , Linux Kernel Mailing List , Andreas Brief , Martin Runge Date: Mon, 10 Mar 2014 21:03:24 +0100 In-Reply-To: References: <20140307013833.GD8427@localhost> <1394176888.1018.3.camel@wall-e.seibold.net> <1394229220.20013.13.camel@wall-e.seibold.net> <1394354848.1002.37.camel@wall-e.seibold.net> <531D044C.2090303@linux.intel.com> <531DD35A.5060202@linux.intel.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Authenticated-Sender: stefani@seibold.net Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am Montag, den 10.03.2014, 10:12 -0700 schrieb Andy Lutomirski: > On Mon, Mar 10, 2014 at 8:11 AM, Linus Torvalds > wrote: > > > > On Mar 10, 2014 8:01 AM, "H. Peter Anvin" 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. > > > > > That would actually be preferable in a few ways, notably not having to mark > > page directories user accessible in the kennel space area. > > Is that where the rabid pte dogs live? > > We can already avoid making fixmap pages user-accessible in the > !compat_vdso case for 32-bit tasks -- the vdso lives in a couple of > more-or-less ordinary vmas. > What is now the next step? Kick out the compat VDSO? Or should i implement the dual VDSO. And what is now the preferred way to map the VDSO into the user space? Using install_special_mapping() or map it beyond the user stack? The is easiest and fastest way to get a working result is to do the non compat VDSO only mapping using install_special_mapping(). The dual VDSO would take a little bit more time. It would be great to have first a consensus about the design before i start to implement ;-) - Stefani