From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Rutland Subject: Re: [PATCHv3 2/2] arch: Rename CONFIG_DEBUG_RODATA and CONFIG_DEBUG_MODULE_RONX Date: Fri, 17 Feb 2017 18:23:13 +0000 Message-ID: <20170217182313.GB25876@leverpostej> References: <1486427518-14819-1-git-send-email-labbott@redhat.com> <1486427518-14819-3-git-send-email-labbott@redhat.com> <20170216222529.GA7531@amd> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Pavel Machek , Laura Abbott , "linux-doc@vger.kernel.org" , Catalin Marinas , Heiko Carstens , "James E.J. Bottomley" , "H. Peter Anvin" , "kernel-hardening@lists.openwall.com" , Rob Herring , Jessica Yu , Jonathan Corbet , Helge Deller , "x86@kernel.org" , Russell King , Ingo Molnar , Len Brown , "linux-s390@vger.kernel.org" , Will Deacon , Thomas Gleixner , To: Kees Cook Return-path: In-Reply-To: List-ID: List-Id: linux-parisc.vger.kernel.org On Thu, Feb 16, 2017 at 05:08:20PM -0800, Kees Cook wrote: > On Thu, Feb 16, 2017 at 2:25 PM, Pavel Machek wrote: > > Hi! > > > >> > >> -config DEBUG_RODATA > >> +config STRICT_KERNEL_RWX > >> bool "Make kernel text and rodata read-only" if ARCH_OPTIONAL_KERNEL_RWX > >> depends on ARCH_HAS_STRICT_KERNEL_RWX > >> default !ARCH_OPTIONAL_KERNEL_RWX || > > > > Debug features are expected to have runtime cost, so kconfig help is > > silent about those. But there are runtime costs, right? It would be > > nice to mention them in the help text... > > It depends on the architecture. The prior help text for arm said: > > The tradeoff is that each region is padded to section-size (1MiB) > boundaries (because their permissions are different and splitting > the 1M pages into 4K ones causes TLB performance problems), which > can waste memory. > > parisc (somewhat inaccurately) said: > > This option may have a slight performance impact because a > portion of the kernel code won't be covered by a TLB anymore. > > IIUC, arm64 does what parisc is hinting at: mappings at the end are > broken down to PAGE_SIZE. On x86, IIUC, there's actually no change to > TLB performance due to how the mappings are already set up. On arm64, we split down to page granularity if needed, but use the largest possible mapping we can (e.g. if we can use a 2M block, we do). Because of the way we freed the init area, we already couldn't use larger mappings anyway. Applying the strict permissions didn't come at a measureable overhead in any real testing. > I'm not sure the best way to express this in the new help text. Do you > have some suggestions on wording? Personally, I don't really think > it's worth mentioning this in Kconfig help, which, in theory, is > supposed to limit how technical it gets. And I think the performance > impact is almost entirely negligible compared to the risks addressed. I also don't see much point in describing some hypothetical architecture specific overhead here. In most cases this can't be turned off (so there isn't anything to comapre it to, and hence no cost). Where people want to turn it off, they already know why they wish to do so. Thanks, Mark. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934785AbdBQSXb (ORCPT ); Fri, 17 Feb 2017 13:23:31 -0500 Received: from foss.arm.com ([217.140.101.70]:58688 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934232AbdBQSX1 (ORCPT ); Fri, 17 Feb 2017 13:23:27 -0500 Date: Fri, 17 Feb 2017 18:23:13 +0000 From: Mark Rutland To: Kees Cook Cc: Pavel Machek , Laura Abbott , "linux-doc@vger.kernel.org" , Catalin Marinas , Heiko Carstens , "James E.J. Bottomley" , "H. Peter Anvin" , "kernel-hardening@lists.openwall.com" , Rob Herring , Jessica Yu , Jonathan Corbet , Helge Deller , "x86@kernel.org" , Russell King , Ingo Molnar , Len Brown , "linux-s390@vger.kernel.org" , Will Deacon , Thomas Gleixner , "linux-arm-kernel@lists.infradead.org" , linux-parisc , Linux PM list , "Rafael J. Wysocki" , LKML , Jason Wessel , Martin Schwidefsky , Robin Murphy Subject: Re: [PATCHv3 2/2] arch: Rename CONFIG_DEBUG_RODATA and CONFIG_DEBUG_MODULE_RONX Message-ID: <20170217182313.GB25876@leverpostej> References: <1486427518-14819-1-git-send-email-labbott@redhat.com> <1486427518-14819-3-git-send-email-labbott@redhat.com> <20170216222529.GA7531@amd> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 16, 2017 at 05:08:20PM -0800, Kees Cook wrote: > On Thu, Feb 16, 2017 at 2:25 PM, Pavel Machek wrote: > > Hi! > > > >> > >> -config DEBUG_RODATA > >> +config STRICT_KERNEL_RWX > >> bool "Make kernel text and rodata read-only" if ARCH_OPTIONAL_KERNEL_RWX > >> depends on ARCH_HAS_STRICT_KERNEL_RWX > >> default !ARCH_OPTIONAL_KERNEL_RWX || > > > > Debug features are expected to have runtime cost, so kconfig help is > > silent about those. But there are runtime costs, right? It would be > > nice to mention them in the help text... > > It depends on the architecture. The prior help text for arm said: > > The tradeoff is that each region is padded to section-size (1MiB) > boundaries (because their permissions are different and splitting > the 1M pages into 4K ones causes TLB performance problems), which > can waste memory. > > parisc (somewhat inaccurately) said: > > This option may have a slight performance impact because a > portion of the kernel code won't be covered by a TLB anymore. > > IIUC, arm64 does what parisc is hinting at: mappings at the end are > broken down to PAGE_SIZE. On x86, IIUC, there's actually no change to > TLB performance due to how the mappings are already set up. On arm64, we split down to page granularity if needed, but use the largest possible mapping we can (e.g. if we can use a 2M block, we do). Because of the way we freed the init area, we already couldn't use larger mappings anyway. Applying the strict permissions didn't come at a measureable overhead in any real testing. > I'm not sure the best way to express this in the new help text. Do you > have some suggestions on wording? Personally, I don't really think > it's worth mentioning this in Kconfig help, which, in theory, is > supposed to limit how technical it gets. And I think the performance > impact is almost entirely negligible compared to the risks addressed. I also don't see much point in describing some hypothetical architecture specific overhead here. In most cases this can't be turned off (so there isn't anything to comapre it to, and hence no cost). Where people want to turn it off, they already know why they wish to do so. Thanks, Mark. From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 17 Feb 2017 18:23:13 +0000 From: Mark Rutland Message-ID: <20170217182313.GB25876@leverpostej> References: <1486427518-14819-1-git-send-email-labbott@redhat.com> <1486427518-14819-3-git-send-email-labbott@redhat.com> <20170216222529.GA7531@amd> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: [kernel-hardening] Re: [PATCHv3 2/2] arch: Rename CONFIG_DEBUG_RODATA and CONFIG_DEBUG_MODULE_RONX List-Archive: List-Post: To: Kees Cook Cc: Pavel Machek , Laura Abbott , "linux-doc@vger.kernel.org" , Catalin Marinas , Heiko Carstens , "James E.J. Bottomley" , "H. Peter Anvin" , "kernel-hardening@lists.openwall.com" , Rob Herring , Jessica Yu , Jonathan Corbet , Helge Deller , "x86@kernel.org" , Russell King , Ingo Molnar , Len Brown , "linux-s390@vger.kernel.org" , Will Deacon , Thomas Gleixner , "linux-arm-kernel@lists.infradead.org" , linux-parisc , Linux PM list , "Rafael J. Wysocki" , LKML , Jason Wessel , Martin Schwidefsky , Robin Murphy List-ID: On Thu, Feb 16, 2017 at 05:08:20PM -0800, Kees Cook wrote: > On Thu, Feb 16, 2017 at 2:25 PM, Pavel Machek wrote: > > Hi! > > > >> > >> -config DEBUG_RODATA > >> +config STRICT_KERNEL_RWX > >> bool "Make kernel text and rodata read-only" if ARCH_OPTIONAL_KERNEL_RWX > >> depends on ARCH_HAS_STRICT_KERNEL_RWX > >> default !ARCH_OPTIONAL_KERNEL_RWX || > > > > Debug features are expected to have runtime cost, so kconfig help is > > silent about those. But there are runtime costs, right? It would be > > nice to mention them in the help text... > > It depends on the architecture. The prior help text for arm said: > > The tradeoff is that each region is padded to section-size (1MiB) > boundaries (because their permissions are different and splitting > the 1M pages into 4K ones causes TLB performance problems), which > can waste memory. > > parisc (somewhat inaccurately) said: > > This option may have a slight performance impact because a > portion of the kernel code won't be covered by a TLB anymore. > > IIUC, arm64 does what parisc is hinting at: mappings at the end are > broken down to PAGE_SIZE. On x86, IIUC, there's actually no change to > TLB performance due to how the mappings are already set up. On arm64, we split down to page granularity if needed, but use the largest possible mapping we can (e.g. if we can use a 2M block, we do). Because of the way we freed the init area, we already couldn't use larger mappings anyway. Applying the strict permissions didn't come at a measureable overhead in any real testing. > I'm not sure the best way to express this in the new help text. Do you > have some suggestions on wording? Personally, I don't really think > it's worth mentioning this in Kconfig help, which, in theory, is > supposed to limit how technical it gets. And I think the performance > impact is almost entirely negligible compared to the risks addressed. I also don't see much point in describing some hypothetical architecture specific overhead here. In most cases this can't be turned off (so there isn't anything to comapre it to, and hence no cost). Where people want to turn it off, they already know why they wish to do so. Thanks, Mark. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Rutland Subject: Re: [PATCHv3 2/2] arch: Rename CONFIG_DEBUG_RODATA and CONFIG_DEBUG_MODULE_RONX Date: Fri, 17 Feb 2017 18:23:13 +0000 Message-ID: <20170217182313.GB25876@leverpostej> References: <1486427518-14819-1-git-send-email-labbott@redhat.com> <1486427518-14819-3-git-send-email-labbott@redhat.com> <20170216222529.GA7531@amd> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from foss.arm.com ([217.140.101.70]:58688 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934232AbdBQSX1 (ORCPT ); Fri, 17 Feb 2017 13:23:27 -0500 Content-Disposition: inline In-Reply-To: Sender: linux-pm-owner@vger.kernel.org List-Id: linux-pm@vger.kernel.org To: Kees Cook Cc: Pavel Machek , Laura Abbott , "linux-doc@vger.kernel.org" , Catalin Marinas , Heiko Carstens , "James E.J. Bottomley" , "H. Peter Anvin" , "kernel-hardening@lists.openwall.com" , Rob Herring , Jessica Yu , Jonathan Corbet , Helge Deller , "x86@kernel.org" , Russell King , Ingo Molnar , Len Brown , "linux-s390@vger.kernel.org" , Will Deacon , Thomas Gleixner On Thu, Feb 16, 2017 at 05:08:20PM -0800, Kees Cook wrote: > On Thu, Feb 16, 2017 at 2:25 PM, Pavel Machek wrote: > > Hi! > > > >> > >> -config DEBUG_RODATA > >> +config STRICT_KERNEL_RWX > >> bool "Make kernel text and rodata read-only" if ARCH_OPTIONAL_KERNEL_RWX > >> depends on ARCH_HAS_STRICT_KERNEL_RWX > >> default !ARCH_OPTIONAL_KERNEL_RWX || > > > > Debug features are expected to have runtime cost, so kconfig help is > > silent about those. But there are runtime costs, right? It would be > > nice to mention them in the help text... > > It depends on the architecture. The prior help text for arm said: > > The tradeoff is that each region is padded to section-size (1MiB) > boundaries (because their permissions are different and splitting > the 1M pages into 4K ones causes TLB performance problems), which > can waste memory. > > parisc (somewhat inaccurately) said: > > This option may have a slight performance impact because a > portion of the kernel code won't be covered by a TLB anymore. > > IIUC, arm64 does what parisc is hinting at: mappings at the end are > broken down to PAGE_SIZE. On x86, IIUC, there's actually no change to > TLB performance due to how the mappings are already set up. On arm64, we split down to page granularity if needed, but use the largest possible mapping we can (e.g. if we can use a 2M block, we do). Because of the way we freed the init area, we already couldn't use larger mappings anyway. Applying the strict permissions didn't come at a measureable overhead in any real testing. > I'm not sure the best way to express this in the new help text. Do you > have some suggestions on wording? Personally, I don't really think > it's worth mentioning this in Kconfig help, which, in theory, is > supposed to limit how technical it gets. And I think the performance > impact is almost entirely negligible compared to the risks addressed. I also don't see much point in describing some hypothetical architecture specific overhead here. In most cases this can't be turned off (so there isn't anything to comapre it to, and hence no cost). Where people want to turn it off, they already know why they wish to do so. Thanks, Mark. From mboxrd@z Thu Jan 1 00:00:00 1970 From: mark.rutland@arm.com (Mark Rutland) Date: Fri, 17 Feb 2017 18:23:13 +0000 Subject: [PATCHv3 2/2] arch: Rename CONFIG_DEBUG_RODATA and CONFIG_DEBUG_MODULE_RONX In-Reply-To: References: <1486427518-14819-1-git-send-email-labbott@redhat.com> <1486427518-14819-3-git-send-email-labbott@redhat.com> <20170216222529.GA7531@amd> Message-ID: <20170217182313.GB25876@leverpostej> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thu, Feb 16, 2017 at 05:08:20PM -0800, Kees Cook wrote: > On Thu, Feb 16, 2017 at 2:25 PM, Pavel Machek wrote: > > Hi! > > > >> > >> -config DEBUG_RODATA > >> +config STRICT_KERNEL_RWX > >> bool "Make kernel text and rodata read-only" if ARCH_OPTIONAL_KERNEL_RWX > >> depends on ARCH_HAS_STRICT_KERNEL_RWX > >> default !ARCH_OPTIONAL_KERNEL_RWX || > > > > Debug features are expected to have runtime cost, so kconfig help is > > silent about those. But there are runtime costs, right? It would be > > nice to mention them in the help text... > > It depends on the architecture. The prior help text for arm said: > > The tradeoff is that each region is padded to section-size (1MiB) > boundaries (because their permissions are different and splitting > the 1M pages into 4K ones causes TLB performance problems), which > can waste memory. > > parisc (somewhat inaccurately) said: > > This option may have a slight performance impact because a > portion of the kernel code won't be covered by a TLB anymore. > > IIUC, arm64 does what parisc is hinting at: mappings at the end are > broken down to PAGE_SIZE. On x86, IIUC, there's actually no change to > TLB performance due to how the mappings are already set up. On arm64, we split down to page granularity if needed, but use the largest possible mapping we can (e.g. if we can use a 2M block, we do). Because of the way we freed the init area, we already couldn't use larger mappings anyway. Applying the strict permissions didn't come at a measureable overhead in any real testing. > I'm not sure the best way to express this in the new help text. Do you > have some suggestions on wording? Personally, I don't really think > it's worth mentioning this in Kconfig help, which, in theory, is > supposed to limit how technical it gets. And I think the performance > impact is almost entirely negligible compared to the risks addressed. I also don't see much point in describing some hypothetical architecture specific overhead here. In most cases this can't be turned off (so there isn't anything to comapre it to, and hence no cost). Where people want to turn it off, they already know why they wish to do so. Thanks, Mark.