On Fri, Feb 03, 2017 at 11:45:56AM -0800, Kees Cook wrote: > On Fri, Feb 3, 2017 at 9:52 AM, Laura Abbott <labbott@xxxxxxxxxx> wrote: > > diff --git a/arch/Kconfig b/arch/Kconfig > > index 99839c2..22ee01e 100644 > > --- a/arch/Kconfig > > +++ b/arch/Kconfig > > @@ -781,4 +781,32 @@ config VMAP_STACK > > the stack to map directly to the KASAN shadow map using a formula > > that is incorrect if the stack is in vmalloc space. > > > > +config ARCH_NO_STRICT_RWX_DEFAULTS > > + def_bool n > > + > > +config ARCH_HAS_STRICT_KERNEL_RWX > > + def_bool n > > + > > +config DEBUG_RODATA > > + def_bool y if !ARCH_NO_STRICT_RWX_DEFAULTS > > + prompt "Make kernel text and rodata read-only" if ARCH_NO_STRICT_RWX_DEFAULTS > > Ah! Yes, perfect. I totally forgot about using conditional "prompt" > lines. Nice! It's no different from the more usual: bool "Make kernel text and rodata read-only" if ARCH_NO_STRICT_RWX_DEFAULTS default y if !ARCH_NO_STRICT_RWX_DEFAULTS depends on ARCH_HAS_STRICT_KERNEL_RWX But... I really don't like this - way too many negations and negatives which make it difficult to figure out what's going on here. The situation we have today is: -config DEBUG_RODATA - bool "Make kernel text and rodata read-only" - depends on MMU && !XIP_KERNEL - default y if CPU_V7 which is "allow the user to select DEBUG_RODATA if building a MMU non-XIP kernel", suggesting that the user turns it on for ARMv7 CPUs. That changes with this and the above: + select ARCH_HAS_STRICT_KERNEL_RWX if MMU && !XIP_KERNEL + select ARCH_HAS_STRICT_MODULE_RWX if MMU + select ARCH_NO_STRICT_RWX_DEFAULTS if !CPU_V7 This means that ARCH_HAS_STRICT_KERNEL_RWX is set for a MMU non-XIP kernel, which carries the same pre-condition for DEBUG_RODATA - no problem there. However, ARCH_NO_STRICT_RWX_DEFAULTS is set for non-ARMv7 CPUs, which means the "Make kernel text and rodata read-only" prompt _is_ provided for those. However, for all ARMv7 systems, we go from "suggesting that the user enables the option" to "you don't have a choice, you get this whether you want it or not." I'd prefer to keep it off for my development systems, where I don't care about kernel security. If we don't wish to do that as a general rule, can we make it dependent on EMBEDDED? Given that on ARM it can add up to 4MB to the kernel image - there _will_ be about 1MB before the .text section, the padding on between __modver and __ex_table which for me is around 626k, the padding between .notes and the init sections start with .vectors (the space between __ex_table and end of .notes is only 4124, which gets padded up to 1MB) and lastly the padding between the .init section and the data section (for me around 593k). This all adds up to an increase in kernel image size of 3.2MB on 14.2MB - an increase of 22%. So no, I'm really not happy with that. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
