From mboxrd@z Thu Jan 1 00:00:00 1970 From: Helge Deller Subject: Re: [PATCHv3 2/2] arch: Rename CONFIG_DEBUG_RODATA and CONFIG_DEBUG_MODULE_RONX Date: Fri, 17 Feb 2017 09:22:44 +0100 Message-ID: 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=utf-8 Cc: Laura Abbott , Mark Rutland , "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 , "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 , Pavel Machek Return-path: List-Post: List-Help: List-Unsubscribe: List-Subscribe: In-Reply-To: List-ID: On 17.02.2017 02:08, 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. The logic on parisc is actually: If huge page support is enabled, we map 1MB pages (and behave like arm wrt alignments). If huge page support is disabled we stay at 4k/PAGE_SIZE pages (without 1M alignment). > IIUC, arm64 does what parisc is hinting at: mappings at the end are > broken down to PAGE_SIZE. On parisc we never implemented that. > On x86, IIUC, there's actually no change to > TLB performance due to how the mappings are already set up. > > 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, I agree on this. > 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. Helge From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755925AbdBQIZP (ORCPT ); Fri, 17 Feb 2017 03:25:15 -0500 Received: from mout.gmx.net ([212.227.17.21]:49166 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753622AbdBQIZL (ORCPT ); Fri, 17 Feb 2017 03:25:11 -0500 Subject: Re: [PATCHv3 2/2] arch: Rename CONFIG_DEBUG_RODATA and CONFIG_DEBUG_MODULE_RONX To: Kees Cook , Pavel Machek Cc: Laura Abbott , Mark Rutland , "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 , "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 References: <1486427518-14819-1-git-send-email-labbott@redhat.com> <1486427518-14819-3-git-send-email-labbott@redhat.com> <20170216222529.GA7531@amd> From: Helge Deller Message-ID: Date: Fri, 17 Feb 2017 09:22:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:F2mdACu6UmoA+gq7dFzhomDgqqrbpY90oIswtRRACRZ6CNvpr46 XvekghCHN/hfSQyv2RK501TEAn2qgNw0XkHzFyNiAkeRky78QrgaQi2iVALUB2qLUAtTHt6 K0l+U6fh8QmX5QuXV3NNdEG2CVkkcBXuF7MRWKNa7lgwTa/kroBTPYgVj4+rnG3bsnJfzcu /cOqSNNr0r4/yfrmw+wXA== X-UI-Out-Filterresults: notjunk:1;V01:K0:m8DT7OqdcfY=:xPyhpt12BXFLNP7Upgub8s PNk91Xe6ocMJ5mLKIDggKa2lNlFOoMQNTRCEY57roYAGkIx4c6zeUIqDi611wDkkx6o41nhKt 3/ykwDY1WxP4fQMeEpb+t60R7tOL0srt2XARmxsw71AcKzsY3rbijGVBkUUc7bOgDby6y4ni3 Nem8WUAsb0eF5sHyEqhEn26aBMgWfDQ/pnUHHjALgXYc3yHsK/XAb6bJK4quFhqv5hsxaOGSw 5QwY7e2+7bVuwzjgRpwpFPvKOHWVnAyJs/8adBi1+SeAZnVGl5gYJSrssbNMEJhH2pAmJDDwQ lW8KaQx5Lz4t342pITvb24O9OIW7xqcceK0DDNfTX5hZ65IMNN3HKJibFabIcPBhuDOGOzJYy +tdkV+q0hRdvuAjDH/a4/typLX43aGyCmjUaZwae89mZjm0c0qd/Ef7Jmz6Q0JgVd2RSCTd26 21N0+7b4US7JfzJcdpAcBVV6j2sE28kO79pPEW9rW/bW43lv5d79sfblGQT3ztiHHGs8fx2fC fFcXPTYlZuM819V9kJLAISTFu0BhRd6HVCuFL9Szzpkq+FrdOEuqwRUoGa7cbpaIVwk9cl5wT FeqSuDmdPAQhZ8g7Y6NNiiC+chYIUupZqe/1nQGkpprRpVKY4vM4qW4ak56Cvrsd9aD+lkW92 ObW5rjByDaxiBvj8R2shSJVLVvjMbSA9cY41g4eiLq28koOY4SUrOEZwpTDScRGdb8vSiNznB FRl7Z2hMmwhDtP9klZMw6fdZy7zEaQLW5LfrSLsHdDPwJziO2gcWB9rjf6YhTUtNag7lW5ZAU xBrHuT3 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 17.02.2017 02:08, 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. The logic on parisc is actually: If huge page support is enabled, we map 1MB pages (and behave like arm wrt alignments). If huge page support is disabled we stay at 4k/PAGE_SIZE pages (without 1M alignment). > IIUC, arm64 does what parisc is hinting at: mappings at the end are > broken down to PAGE_SIZE. On parisc we never implemented that. > On x86, IIUC, there's actually no change to > TLB performance due to how the mappings are already set up. > > 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, I agree on this. > 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. Helge From mboxrd@z Thu Jan 1 00:00:00 1970 References: <1486427518-14819-1-git-send-email-labbott@redhat.com> <1486427518-14819-3-git-send-email-labbott@redhat.com> <20170216222529.GA7531@amd> From: Helge Deller Message-ID: Date: Fri, 17 Feb 2017 09:22:44 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: [kernel-hardening] Re: [PATCHv3 2/2] arch: Rename CONFIG_DEBUG_RODATA and CONFIG_DEBUG_MODULE_RONX List-Archive: List-Post: To: Kees Cook , Pavel Machek Cc: Laura Abbott , Mark Rutland , "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 , "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 17.02.2017 02:08, 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. The logic on parisc is actually: If huge page support is enabled, we map 1MB pages (and behave like arm wrt alignments). If huge page support is disabled we stay at 4k/PAGE_SIZE pages (without 1M alignment). > IIUC, arm64 does what parisc is hinting at: mappings at the end are > broken down to PAGE_SIZE. On parisc we never implemented that. > On x86, IIUC, there's actually no change to > TLB performance due to how the mappings are already set up. > > 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, I agree on this. > 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. Helge From mboxrd@z Thu Jan 1 00:00:00 1970 From: Helge Deller Subject: Re: [PATCHv3 2/2] arch: Rename CONFIG_DEBUG_RODATA and CONFIG_DEBUG_MODULE_RONX Date: Fri, 17 Feb 2017 09:22:44 +0100 Message-ID: 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=utf-8 Content-Transfer-Encoding: 7bit Return-path: List-Post: List-Help: List-Unsubscribe: List-Subscribe: In-Reply-To: To: Kees Cook , Pavel Machek Cc: Laura Abbott , Mark Rutland , "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 , "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 List-Id: linux-pm@vger.kernel.org On 17.02.2017 02:08, 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. The logic on parisc is actually: If huge page support is enabled, we map 1MB pages (and behave like arm wrt alignments). If huge page support is disabled we stay at 4k/PAGE_SIZE pages (without 1M alignment). > IIUC, arm64 does what parisc is hinting at: mappings at the end are > broken down to PAGE_SIZE. On parisc we never implemented that. > On x86, IIUC, there's actually no change to > TLB performance due to how the mappings are already set up. > > 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, I agree on this. > 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. Helge From mboxrd@z Thu Jan 1 00:00:00 1970 From: deller@gmx.de (Helge Deller) Date: Fri, 17 Feb 2017 09:22:44 +0100 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: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 17.02.2017 02:08, 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. The logic on parisc is actually: If huge page support is enabled, we map 1MB pages (and behave like arm wrt alignments). If huge page support is disabled we stay at 4k/PAGE_SIZE pages (without 1M alignment). > IIUC, arm64 does what parisc is hinting at: mappings at the end are > broken down to PAGE_SIZE. On parisc we never implemented that. > On x86, IIUC, there's actually no change to > TLB performance due to how the mappings are already set up. > > 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, I agree on this. > 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. Helge