From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kees Cook Subject: Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core) Date: Tue, 21 Jun 2016 13:18:38 -0700 Message-ID: References: <13212319.WrhLzgRA6Z@wuerfel> <6248429.A4IJrfgOW3@wuerfel> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Andy Lutomirski Cc: Arnd Bergmann , Andy Lutomirski , "x86@kernel.org" , LKML , linux-arch , Borislav Petkov , Nadav Amit , Brian Gerst , "kernel-hardening@lists.openwall.com" , Linus Torvalds , Josh Poimboeuf , Jann Horn , Heiko Carstens List-Id: linux-arch.vger.kernel.org On Tue, Jun 21, 2016 at 12:47 PM, Andy Lutomirski = wrote: > On Tue, Jun 21, 2016 at 12:47 PM, Arnd Bergmann wrote= : >> On Tuesday, June 21, 2016 10:16:21 AM CEST Kees Cook wrote: >>> On Tue, Jun 21, 2016 at 2:24 AM, Arnd Bergmann wrot= e: >>> > On Monday, June 20, 2016 4:43:30 PM CEST Andy Lutomirski wrote: >>> >> >>> >> On my laptop, this adds about 1.5=C2=B5s of overhead to task cre= ation, >>> >> which seems to be mainly caused by vmalloc inefficiently allocat= ing >>> >> individual pages even when a higher-order page is available on t= he >>> >> freelist. >>> > >>> > Would it help to have a fixed virtual address for the stack inste= ad >>> > and map the current stack to that during a task switch, similar t= o >>> > how we handle fixmap pages? >>> > >>> > That would of course trade the allocation overhead for a task swi= tch >>> > overhead, which may be better or worse. It would also give "curre= nt" >>> > a constant address, which may give a small performance advantage >>> > but may also introduce a new attack vector unless we randomize it >>> > again. >>> >>> Right: we don't want a fixed address. That makes attacks WAY easier= =2E >> >> Do we care about making the address more random then? When I look >> at /proc/vmallocinfo, I see that allocations are all using >> consecutive addresses, so if you can figure out the virtual >> address of the stack for one process that would give you a good >> chance of guessing the address for the next pid. > > Quite possibly. We should seriously consider at least randomizing th= e > *start* of the vmalloc area, at least on 64-bit architectures. Yup, this is already under way for x86. Thomas Garnier has a series that he's been working on: http://git.kernel.org/cgit/linux/kernel/git/kees/linux.git/log/?h=3Dkas= lr/memory I'd love to see similar for other architectures too. Thomas just sent me an updated series I'll be putting up for review lat= er today. -Kees --=20 Kees Cook Chrome OS & Brillo Security From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-f53.google.com ([209.85.215.53]:33318 "EHLO mail-lf0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751659AbcFUUSm convert rfc822-to-8bit (ORCPT ); Tue, 21 Jun 2016 16:18:42 -0400 Received: by mail-lf0-f53.google.com with SMTP id f6so41323169lfg.0 for ; Tue, 21 Jun 2016 13:18:41 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <13212319.WrhLzgRA6Z@wuerfel> <6248429.A4IJrfgOW3@wuerfel> From: Kees Cook Date: Tue, 21 Jun 2016 13:18:38 -0700 Message-ID: Subject: Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core) Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-arch-owner@vger.kernel.org List-ID: To: Andy Lutomirski Cc: Arnd Bergmann , Andy Lutomirski , "x86@kernel.org" , LKML , linux-arch , Borislav Petkov , Nadav Amit , Brian Gerst , "kernel-hardening@lists.openwall.com" , Linus Torvalds , Josh Poimboeuf , Jann Horn , Heiko Carstens Message-ID: <20160621201838.iUcgHKgDSFBZ8SZmS4Db1Bo-Y-R77zXvCICu0PrBM1Y@z> On Tue, Jun 21, 2016 at 12:47 PM, Andy Lutomirski wrote: > On Tue, Jun 21, 2016 at 12:47 PM, Arnd Bergmann wrote: >> On Tuesday, June 21, 2016 10:16:21 AM CEST Kees Cook wrote: >>> On Tue, Jun 21, 2016 at 2:24 AM, Arnd Bergmann wrote: >>> > On Monday, June 20, 2016 4:43:30 PM CEST Andy Lutomirski wrote: >>> >> >>> >> On my laptop, this adds about 1.5µs of overhead to task creation, >>> >> which seems to be mainly caused by vmalloc inefficiently allocating >>> >> individual pages even when a higher-order page is available on the >>> >> freelist. >>> > >>> > Would it help to have a fixed virtual address for the stack instead >>> > and map the current stack to that during a task switch, similar to >>> > how we handle fixmap pages? >>> > >>> > That would of course trade the allocation overhead for a task switch >>> > overhead, which may be better or worse. It would also give "current" >>> > a constant address, which may give a small performance advantage >>> > but may also introduce a new attack vector unless we randomize it >>> > again. >>> >>> Right: we don't want a fixed address. That makes attacks WAY easier. >> >> Do we care about making the address more random then? When I look >> at /proc/vmallocinfo, I see that allocations are all using >> consecutive addresses, so if you can figure out the virtual >> address of the stack for one process that would give you a good >> chance of guessing the address for the next pid. > > Quite possibly. We should seriously consider at least randomizing the > *start* of the vmalloc area, at least on 64-bit architectures. Yup, this is already under way for x86. Thomas Garnier has a series that he's been working on: http://git.kernel.org/cgit/linux/kernel/git/kees/linux.git/log/?h=kaslr/memory I'd love to see similar for other architectures too. Thomas just sent me an updated series I'll be putting up for review later today. -Kees -- Kees Cook Chrome OS & Brillo Security