From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752048AbcFUTs0 (ORCPT ); Tue, 21 Jun 2016 15:48:26 -0400 Received: from mail-vk0-f43.google.com ([209.85.213.43]:33792 "EHLO mail-vk0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751599AbcFUTrt convert rfc822-to-8bit (ORCPT ); Tue, 21 Jun 2016 15:47:49 -0400 MIME-Version: 1.0 In-Reply-To: <6248429.A4IJrfgOW3@wuerfel> References: <13212319.WrhLzgRA6Z@wuerfel> <6248429.A4IJrfgOW3@wuerfel> From: Andy Lutomirski Date: Tue, 21 Jun 2016 12:47:28 -0700 Message-ID: Subject: Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core) To: Arnd Bergmann Cc: Kees Cook , 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. --Andy From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Lutomirski Subject: Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core) Date: Tue, 21 Jun 2016 12:47:28 -0700 Message-ID: References: <13212319.WrhLzgRA6Z@wuerfel> <6248429.A4IJrfgOW3@wuerfel> Reply-To: kernel-hardening@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: List-Post: List-Help: List-Unsubscribe: List-Subscribe: In-Reply-To: <6248429.A4IJrfgOW3@wuerfel> To: Arnd Bergmann Cc: Kees Cook , 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, 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=C2=B5s 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. --Andy From mboxrd@z Thu Jan 1 00:00:00 1970 Reply-To: kernel-hardening@lists.openwall.com MIME-Version: 1.0 In-Reply-To: <6248429.A4IJrfgOW3@wuerfel> References: <13212319.WrhLzgRA6Z@wuerfel> <6248429.A4IJrfgOW3@wuerfel> From: Andy Lutomirski Date: Tue, 21 Jun 2016 12:47:28 -0700 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [kernel-hardening] Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core) To: Arnd Bergmann Cc: Kees Cook , 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: 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=C2=B5s 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. --Andy