From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751453AbdFZS1G (ORCPT ); Mon, 26 Jun 2017 14:27:06 -0400 Received: from mail-it0-f45.google.com ([209.85.214.45]:35095 "EHLO mail-it0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751308AbdFZS1B (ORCPT ); Mon, 26 Jun 2017 14:27:01 -0400 MIME-Version: 1.0 In-Reply-To: <8737amew79.fsf@concordia.ellerman.id.au> References: <1498154792-49952-1-git-send-email-keescook@chromium.org> <1498154792-49952-4-git-send-email-keescook@chromium.org> <87podvp4q1.fsf@concordia.ellerman.id.au> <8737amew79.fsf@concordia.ellerman.id.au> From: Kees Cook Date: Mon, 26 Jun 2017 11:26:59 -0700 X-Google-Sender-Auth: h9mUZY4FFnuW5keEzrNiNhMUgLE Message-ID: Subject: Re: [PATCH 3/4] powerpc: Reduce ELF_ET_DYN_BASE To: Michael Ellerman Cc: Andrew Morton , Russell King , Catalin Marinas , Will Deacon , Benjamin Herrenschmidt , Paul Mackerras , Martin Schwidefsky , Heiko Carstens , James Hogan , Pratyush Anand , Ingo Molnar , "linux-arm-kernel@lists.infradead.org" , "linuxppc-dev@lists.ozlabs.org" , "linux-s390@vger.kernel.org" , LKML , linux-arch , "kernel-hardening@lists.openwall.com" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 26, 2017 at 6:04 AM, Michael Ellerman wrote: > Kees Cook writes: > >> On Fri, Jun 23, 2017 at 12:01 AM, Michael Ellerman wrote: >>> Kees Cook writes: >>> >>>> Now that explicitly executed loaders are loaded in the mmap region, >>>> position PIE binaries lower in the address space to avoid possible >>>> collisions with mmap or stack regions. For 64-bit, align to 4GB to >>>> allow runtimes to use the entire 32-bit address space for 32-bit >>>> pointers. >>> >>> The change log and subject are a bit out of whack with the actual patch >>> because previously we used 512MB. >>> >>> How about? >>> >>> powerpc: Move ELF_ET_DYN_BASE to 4GB / 4MB >>> >>> Now that explicitly executed loaders are loaded in the mmap region, >>> we have more freedom to decide where we position PIE binaries in the >>> address space to avoid possible collisions with mmap or stack regions. >>> >>> For 64-bit, align to 4GB to allow runtimes to use the entire 32-bit >>> address space for 32-bit pointers. On 32-bit use 4MB. >> >> Good idea, thanks. I'll resend the series with the commit logs updated. >> >>> Is there any particular reasoning behind the 4MB value on 32-bit? >> >> So, I've dug around a bit on this, and I *think* the rationale is to >> avoid mapping a possible 4MB page table entry when it won't be using >> at least a portion near the lower end (NULL address area covered >> blocked by mmap_min_addr). It seems to be mainly tradition, though. > > OK, that is obscure, especially for CPUs that don't have a 4MB page > size. But consistency across arches is probably best regardless. Yeah, I like being not "close" to the NULL address, though the definition of "close" has been various values like 64K (mmap_min_addr) and 1M (x86 BIOS junk and new stack-gap size). 4MB is above even that, so, I think we're fine there. It's what Windows has used, so it's familiar and any new attack methodologies would at least be shared across OSes and architectures, so we should "notice" any problem with the value, and then we can adjust it if we need to. -Kees -- Kees Cook Pixel Security From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 Sender: keescook@google.com In-Reply-To: <8737amew79.fsf@concordia.ellerman.id.au> References: <1498154792-49952-1-git-send-email-keescook@chromium.org> <1498154792-49952-4-git-send-email-keescook@chromium.org> <87podvp4q1.fsf@concordia.ellerman.id.au> <8737amew79.fsf@concordia.ellerman.id.au> From: Kees Cook Date: Mon, 26 Jun 2017 11:26:59 -0700 Message-ID: Content-Type: text/plain; charset="UTF-8" Subject: [kernel-hardening] Re: [PATCH 3/4] powerpc: Reduce ELF_ET_DYN_BASE List-Archive: List-Post: To: Michael Ellerman Cc: Andrew Morton , Russell King , Catalin Marinas , Will Deacon , Benjamin Herrenschmidt , Paul Mackerras , Martin Schwidefsky , Heiko Carstens , James Hogan , Pratyush Anand , Ingo Molnar , "linux-arm-kernel@lists.infradead.org" , "linuxppc-dev@lists.ozlabs.org" , "linux-s390@vger.kernel.org" , LKML , linux-arch , "kernel-hardening@lists.openwall.com" List-ID: On Mon, Jun 26, 2017 at 6:04 AM, Michael Ellerman wrote: > Kees Cook writes: > >> On Fri, Jun 23, 2017 at 12:01 AM, Michael Ellerman wrote: >>> Kees Cook writes: >>> >>>> Now that explicitly executed loaders are loaded in the mmap region, >>>> position PIE binaries lower in the address space to avoid possible >>>> collisions with mmap or stack regions. For 64-bit, align to 4GB to >>>> allow runtimes to use the entire 32-bit address space for 32-bit >>>> pointers. >>> >>> The change log and subject are a bit out of whack with the actual patch >>> because previously we used 512MB. >>> >>> How about? >>> >>> powerpc: Move ELF_ET_DYN_BASE to 4GB / 4MB >>> >>> Now that explicitly executed loaders are loaded in the mmap region, >>> we have more freedom to decide where we position PIE binaries in the >>> address space to avoid possible collisions with mmap or stack regions. >>> >>> For 64-bit, align to 4GB to allow runtimes to use the entire 32-bit >>> address space for 32-bit pointers. On 32-bit use 4MB. >> >> Good idea, thanks. I'll resend the series with the commit logs updated. >> >>> Is there any particular reasoning behind the 4MB value on 32-bit? >> >> So, I've dug around a bit on this, and I *think* the rationale is to >> avoid mapping a possible 4MB page table entry when it won't be using >> at least a portion near the lower end (NULL address area covered >> blocked by mmap_min_addr). It seems to be mainly tradition, though. > > OK, that is obscure, especially for CPUs that don't have a 4MB page > size. But consistency across arches is probably best regardless. Yeah, I like being not "close" to the NULL address, though the definition of "close" has been various values like 64K (mmap_min_addr) and 1M (x86 BIOS junk and new stack-gap size). 4MB is above even that, so, I think we're fine there. It's what Windows has used, so it's familiar and any new attack methodologies would at least be shared across OSes and architectures, so we should "notice" any problem with the value, and then we can adjust it if we need to. -Kees -- Kees Cook Pixel Security From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kees Cook Subject: Re: [PATCH 3/4] powerpc: Reduce ELF_ET_DYN_BASE Date: Mon, 26 Jun 2017 11:26:59 -0700 Message-ID: References: <1498154792-49952-1-git-send-email-keescook@chromium.org> <1498154792-49952-4-git-send-email-keescook@chromium.org> <87podvp4q1.fsf@concordia.ellerman.id.au> <8737amew79.fsf@concordia.ellerman.id.au> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: <8737amew79.fsf@concordia.ellerman.id.au> Sender: linux-kernel-owner@vger.kernel.org To: Michael Ellerman Cc: Andrew Morton , Russell King , Catalin Marinas , Will Deacon , Benjamin Herrenschmidt , Paul Mackerras , Martin Schwidefsky , Heiko Carstens , James Hogan , Pratyush Anand , Ingo Molnar , "linux-arm-kernel@lists.infradead.org" , "linuxppc-dev@lists.ozlabs.org" , "linux-s390@vger.kernel.org" , LKML , linux-arch , kernel-hardening@lists.openwall.com List-Id: linux-arch.vger.kernel.org On Mon, Jun 26, 2017 at 6:04 AM, Michael Ellerman wrote: > Kees Cook writes: > >> On Fri, Jun 23, 2017 at 12:01 AM, Michael Ellerman wrote: >>> Kees Cook writes: >>> >>>> Now that explicitly executed loaders are loaded in the mmap region, >>>> position PIE binaries lower in the address space to avoid possible >>>> collisions with mmap or stack regions. For 64-bit, align to 4GB to >>>> allow runtimes to use the entire 32-bit address space for 32-bit >>>> pointers. >>> >>> The change log and subject are a bit out of whack with the actual patch >>> because previously we used 512MB. >>> >>> How about? >>> >>> powerpc: Move ELF_ET_DYN_BASE to 4GB / 4MB >>> >>> Now that explicitly executed loaders are loaded in the mmap region, >>> we have more freedom to decide where we position PIE binaries in the >>> address space to avoid possible collisions with mmap or stack regions. >>> >>> For 64-bit, align to 4GB to allow runtimes to use the entire 32-bit >>> address space for 32-bit pointers. On 32-bit use 4MB. >> >> Good idea, thanks. I'll resend the series with the commit logs updated. >> >>> Is there any particular reasoning behind the 4MB value on 32-bit? >> >> So, I've dug around a bit on this, and I *think* the rationale is to >> avoid mapping a possible 4MB page table entry when it won't be using >> at least a portion near the lower end (NULL address area covered >> blocked by mmap_min_addr). It seems to be mainly tradition, though. > > OK, that is obscure, especially for CPUs that don't have a 4MB page > size. But consistency across arches is probably best regardless. Yeah, I like being not "close" to the NULL address, though the definition of "close" has been various values like 64K (mmap_min_addr) and 1M (x86 BIOS junk and new stack-gap size). 4MB is above even that, so, I think we're fine there. It's what Windows has used, so it's familiar and any new attack methodologies would at least be shared across OSes and architectures, so we should "notice" any problem with the value, and then we can adjust it if we need to. -Kees -- Kees Cook Pixel Security From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-f53.google.com ([209.85.214.53]:37376 "EHLO mail-it0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751432AbdFZS1E (ORCPT ); Mon, 26 Jun 2017 14:27:04 -0400 Received: by mail-it0-f53.google.com with SMTP id m84so3419082ita.0 for ; Mon, 26 Jun 2017 11:27:04 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <8737amew79.fsf@concordia.ellerman.id.au> References: <1498154792-49952-1-git-send-email-keescook@chromium.org> <1498154792-49952-4-git-send-email-keescook@chromium.org> <87podvp4q1.fsf@concordia.ellerman.id.au> <8737amew79.fsf@concordia.ellerman.id.au> From: Kees Cook Date: Mon, 26 Jun 2017 11:26:59 -0700 Message-ID: Subject: Re: [PATCH 3/4] powerpc: Reduce ELF_ET_DYN_BASE Content-Type: text/plain; charset="UTF-8" Sender: linux-arch-owner@vger.kernel.org List-ID: To: Michael Ellerman Cc: Andrew Morton , Russell King , Catalin Marinas , Will Deacon , Benjamin Herrenschmidt , Paul Mackerras , Martin Schwidefsky , Heiko Carstens , James Hogan , Pratyush Anand , Ingo Molnar , "linux-arm-kernel@lists.infradead.org" , "linuxppc-dev@lists.ozlabs.org" , "linux-s390@vger.kernel.org" , LKML , linux-arch , "kernel-hardening@lists.openwall.com" Message-ID: <20170626182659.Qd6GPSZ3alklw-DA1QYoOi3AJ6pkFPNLrSuq1VEAbzA@z> On Mon, Jun 26, 2017 at 6:04 AM, Michael Ellerman wrote: > Kees Cook writes: > >> On Fri, Jun 23, 2017 at 12:01 AM, Michael Ellerman wrote: >>> Kees Cook writes: >>> >>>> Now that explicitly executed loaders are loaded in the mmap region, >>>> position PIE binaries lower in the address space to avoid possible >>>> collisions with mmap or stack regions. For 64-bit, align to 4GB to >>>> allow runtimes to use the entire 32-bit address space for 32-bit >>>> pointers. >>> >>> The change log and subject are a bit out of whack with the actual patch >>> because previously we used 512MB. >>> >>> How about? >>> >>> powerpc: Move ELF_ET_DYN_BASE to 4GB / 4MB >>> >>> Now that explicitly executed loaders are loaded in the mmap region, >>> we have more freedom to decide where we position PIE binaries in the >>> address space to avoid possible collisions with mmap or stack regions. >>> >>> For 64-bit, align to 4GB to allow runtimes to use the entire 32-bit >>> address space for 32-bit pointers. On 32-bit use 4MB. >> >> Good idea, thanks. I'll resend the series with the commit logs updated. >> >>> Is there any particular reasoning behind the 4MB value on 32-bit? >> >> So, I've dug around a bit on this, and I *think* the rationale is to >> avoid mapping a possible 4MB page table entry when it won't be using >> at least a portion near the lower end (NULL address area covered >> blocked by mmap_min_addr). It seems to be mainly tradition, though. > > OK, that is obscure, especially for CPUs that don't have a 4MB page > size. But consistency across arches is probably best regardless. Yeah, I like being not "close" to the NULL address, though the definition of "close" has been various values like 64K (mmap_min_addr) and 1M (x86 BIOS junk and new stack-gap size). 4MB is above even that, so, I think we're fine there. It's what Windows has used, so it's familiar and any new attack methodologies would at least be shared across OSes and architectures, so we should "notice" any problem with the value, and then we can adjust it if we need to. -Kees -- Kees Cook Pixel Security From mboxrd@z Thu Jan 1 00:00:00 1970 From: keescook@chromium.org (Kees Cook) Date: Mon, 26 Jun 2017 11:26:59 -0700 Subject: [PATCH 3/4] powerpc: Reduce ELF_ET_DYN_BASE In-Reply-To: <8737amew79.fsf@concordia.ellerman.id.au> References: <1498154792-49952-1-git-send-email-keescook@chromium.org> <1498154792-49952-4-git-send-email-keescook@chromium.org> <87podvp4q1.fsf@concordia.ellerman.id.au> <8737amew79.fsf@concordia.ellerman.id.au> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Mon, Jun 26, 2017 at 6:04 AM, Michael Ellerman wrote: > Kees Cook writes: > >> On Fri, Jun 23, 2017 at 12:01 AM, Michael Ellerman wrote: >>> Kees Cook writes: >>> >>>> Now that explicitly executed loaders are loaded in the mmap region, >>>> position PIE binaries lower in the address space to avoid possible >>>> collisions with mmap or stack regions. For 64-bit, align to 4GB to >>>> allow runtimes to use the entire 32-bit address space for 32-bit >>>> pointers. >>> >>> The change log and subject are a bit out of whack with the actual patch >>> because previously we used 512MB. >>> >>> How about? >>> >>> powerpc: Move ELF_ET_DYN_BASE to 4GB / 4MB >>> >>> Now that explicitly executed loaders are loaded in the mmap region, >>> we have more freedom to decide where we position PIE binaries in the >>> address space to avoid possible collisions with mmap or stack regions. >>> >>> For 64-bit, align to 4GB to allow runtimes to use the entire 32-bit >>> address space for 32-bit pointers. On 32-bit use 4MB. >> >> Good idea, thanks. I'll resend the series with the commit logs updated. >> >>> Is there any particular reasoning behind the 4MB value on 32-bit? >> >> So, I've dug around a bit on this, and I *think* the rationale is to >> avoid mapping a possible 4MB page table entry when it won't be using >> at least a portion near the lower end (NULL address area covered >> blocked by mmap_min_addr). It seems to be mainly tradition, though. > > OK, that is obscure, especially for CPUs that don't have a 4MB page > size. But consistency across arches is probably best regardless. Yeah, I like being not "close" to the NULL address, though the definition of "close" has been various values like 64K (mmap_min_addr) and 1M (x86 BIOS junk and new stack-gap size). 4MB is above even that, so, I think we're fine there. It's what Windows has used, so it's familiar and any new attack methodologies would at least be shared across OSes and architectures, so we should "notice" any problem with the value, and then we can adjust it if we need to. -Kees -- Kees Cook Pixel Security