On Fri, Feb 3, 2017 at 12:29 PM, Russell King - ARM Linux <linux@xxxxxxxxxxxxxxx> wrote: > 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. Ah yeah, good point. We have three cases: unsupported, mandatory, optional, but we have the case of setting the default for the optional case. Maybe something like this? 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_DEFAULT unsupported: !ARCH_HAS_STRICT_KERNEL_RWX mandatory: ARCH_HAS_STRICT_KERNEL_RWX !ARCH_OPTIONAL_KERNEL_RWX optional: ARCH_HAS_STRICT_KERNEL_RWX ARCH_OPTIONAL_KERNEL_RWX with default controlled by ARCH_OPTIONAL_KERNEL_RWX_DEFAULT Then arm is: select ARCH_HAS_STRICT_KERNEL_RWX if MMU && !XIP_KERNEL select ARCH_HAS_STRICT_MODULE_RWX if MMU select ARCH_OPTIONAL_KERNEL_RWX if ARCH_HAS_STRICT_KERNEL_RWX select ARCH_OPTIONAL_KERNEL_RWX_DEFAULT if CPU_V7 x86 and arm64 are: select ARCH_HAS_STRICT_KERNEL_RWX select ARCH_HAS_STRICT_MODULE_RWX ? -Kees -- Kees Cook Pixel Security -- To unsubscribe from this list: send the line "unsubscribe linux-s390" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
