From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751228AbdBTHYI (ORCPT ); Mon, 20 Feb 2017 02:24:08 -0500 Received: from mail-wr0-f195.google.com ([209.85.128.195]:35735 "EHLO mail-wr0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750936AbdBTHYD (ORCPT ); Mon, 20 Feb 2017 02:24:03 -0500 Date: Mon, 20 Feb 2017 08:21:30 +0100 From: Ingo Molnar To: Kees Cook Cc: Pavel Machek , 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 , 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: <20170220072130.GB8974@gmail.com> 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.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * 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. BTW., a good strategy with RAM sizes above say 4GB would be to just round up to the next large-TLB boundary (2MB) and waste 0-2MB of RAM - which is only 0.05% of 4GB of RAM. On most workloads, especially with SSDs it's probably a positive RAM vs. performance trade-off. Thanks, Ingo