[PATCHv2 1/2] arch: Move CONFIG_DEBUG_RODATA and CONFIG_SET_MODULE_RONX to be common
Kees Cook
keescook at chromium.org
Fri Feb 3 13:08:40 PST 2017
On Fri, Feb 3, 2017 at 12:29 PM, Russell King - ARM Linux
<linux at armlinux.org.uk> 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 at redhat.com> 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
More information about the linux-arm-kernel
mailing list