diff mbox

arm: don't allow CONFIG_DEBUG_SET_MODULE_RONX if CONFIG_JUMP_LABEL is enabled

Message ID 1396346657-7166-1-git-send-email-holler@ahsoftware.de (mailing list archive)
State New, archived
Headers show

Commit Message

Alexander Holler April 1, 2014, 10:04 a.m. UTC
CONFIG_DEBUG_SET_MODULE_RONX sounds like a nice security feature, but
things might fail late (and unexpected) if module code is set to read-only
while CONFIG_JUMP_LABEL is enabled (e.g. modprobe bridge).

Avoid this.

Signed-off-by: Alexander Holler <holler@ahsoftware.de>
---
 arch/arm/Kconfig.debug | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Laura Abbott April 1, 2014, 6:03 p.m. UTC | #1
On 4/1/2014 3:04 AM, Alexander Holler wrote:
> CONFIG_DEBUG_SET_MODULE_RONX sounds like a nice security feature, but
> things might fail late (and unexpected) if module code is set to read-only
> while CONFIG_JUMP_LABEL is enabled (e.g. modprobe bridge).
> 
> Avoid this.
> 
> Signed-off-by: Alexander Holler <holler@ahsoftware.de>
> ---
>  arch/arm/Kconfig.debug | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
> index 0531da8..6627b9e 100644
> --- a/arch/arm/Kconfig.debug
> +++ b/arch/arm/Kconfig.debug
> @@ -1197,7 +1197,7 @@ config PID_IN_CONTEXTIDR
>  
>  config DEBUG_SET_MODULE_RONX
>  	bool "Set loadable kernel module data as NX and text as RO"
> -	depends on MODULES
> +	depends on MODULES && !JUMP_LABEL
>  	---help---
>  	  This option helps catch unintended modifications to loadable
>  	  kernel module's text and read-only data. It also prevents execution
> 

Kees Cook has something similar[1] for not-module space as well, we probably want
this there as well. A shame we keep finding reasons these features will be turned
off. Looks good to me otherwise. 

Laura

[1]http://lists.infradead.org/pipermail/linux-arm-kernel/2014-February/232644.html
Kees Cook April 1, 2014, 6:36 p.m. UTC | #2
On Tue, Apr 1, 2014 at 11:03 AM, Laura Abbott <lauraa@codeaurora.org> wrote:
> On 4/1/2014 3:04 AM, Alexander Holler wrote:
>> CONFIG_DEBUG_SET_MODULE_RONX sounds like a nice security feature, but
>> things might fail late (and unexpected) if module code is set to read-only
>> while CONFIG_JUMP_LABEL is enabled (e.g. modprobe bridge).

Isn't this a ordering problem? I thought jump labels got set up once,
and then after that, the memory could be made RO?

>>
>> Avoid this.
>>
>> Signed-off-by: Alexander Holler <holler@ahsoftware.de>
>> ---
>>  arch/arm/Kconfig.debug | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
>> index 0531da8..6627b9e 100644
>> --- a/arch/arm/Kconfig.debug
>> +++ b/arch/arm/Kconfig.debug
>> @@ -1197,7 +1197,7 @@ config PID_IN_CONTEXTIDR
>>
>>  config DEBUG_SET_MODULE_RONX
>>       bool "Set loadable kernel module data as NX and text as RO"
>> -     depends on MODULES
>> +     depends on MODULES && !JUMP_LABEL
>>       ---help---
>>         This option helps catch unintended modifications to loadable
>>         kernel module's text and read-only data. It also prevents execution
>>
>
> Kees Cook has something similar[1] for not-module space as well, we probably want
> this there as well. A shame we keep finding reasons these features will be turned
> off. Looks good to me otherwise.
>
> Laura
>
> [1]http://lists.infradead.org/pipermail/linux-arm-kernel/2014-February/232644.html

I've solidly stumbled over ftrace with my series now. I can't figure
out why it doesn't work, though. I wrote code to flip the PMD flags
back to writable (via set_kernel_text_rw), but it seems like the
system is ignoring the changes, even though I call flush_pmd_entry.

struct section_perm section_perms[] = {
       /* Make kernel code and rodata RX (set RO). */
       [ARM_TEXT_SECTION] = {
              .start       = (unsigned long)_stext,
              .end       = (unsigned long)__init_begin,
#ifdef CONFIG_ARM_LPAE
              .mask       = ~PMD_SECT_RDONLY,
              .prot       = PMD_SECT_RDONLY,
#else
              .mask       = ~(PMD_SECT_APX | PMD_SECT_AP_WRITE),
              .prot       = PMD_SECT_APX | PMD_SECT_AP_WRITE,
              .clear       = PMD_SECT_AP_WRITE,
#endif
       },

...

static inline void section_update(unsigned long addr, pmdval_t mask,
                              pmdval_t prot)
{
       pmd_t *pmd = pmd_off_k(addr);

#ifdef CONFIG_ARM_LPAE
       pmd[0] = __pmd((pmd_val(pmd[0]) & mask) | prot);
#else
       if (addr & SECTION_SIZE)
              pmd[1] = __pmd((pmd_val(pmd[1]) & mask) | prot);
       else
              pmd[0] = __pmd((pmd_val(pmd[0]) & mask) | prot);
#endif
       flush_pmd_entry(pmd);
}

...

void set_kernel_text_rw(void)
{
       unsigned long addr;

       if (!arch_can_set_perms())
              return;

       for (addr = section_perms[ARM_TEXT_SECTION].start;
            addr < section_perms[ARM_TEXT_SECTION].end;
            addr += SECTION_SIZE)
              section_update(addr, section_perms[ARM_TEXT_SECTION].mask,
                            section_perms[ARM_TEXT_SECTION].clear);
}

Is there something "sticky" about PMD sections that I'm not aware of?
Even after calling set_kernel_text_rw(), any writes to kernel memory
fault. :(

-Kees
Alexander Holler April 1, 2014, 6:53 p.m. UTC | #3
Am 01.04.2014 20:36, schrieb Kees Cook:
> On Tue, Apr 1, 2014 at 11:03 AM, Laura Abbott <lauraa@codeaurora.org> wrote:
>> On 4/1/2014 3:04 AM, Alexander Holler wrote:
>>> CONFIG_DEBUG_SET_MODULE_RONX sounds like a nice security feature, but
>>> things might fail late (and unexpected) if module code is set to read-only
>>> while CONFIG_JUMP_LABEL is enabled (e.g. modprobe bridge).
>
> Isn't this a ordering problem? I thought jump labels got set up once,
> and then after that, the memory could be made RO?

I basically just run into that and looked up what happened. But the 
problem appears e.g. in netfiler/core.c function nf_register_hook() 
which calls static_key_slow_inc(). So you would have to make sure 
nf_register_hook() will be called before the code is set ro. Something 
that doesn't look easy to do.

I would have to look up when that might be called, but I assume there 
are many ways to register and unregister hooks in netfilter and some of 
them might happen outside any init, probe or whatever one might set the 
code read-only afterwards. You would have to set the code rw too, before 
nf_unregister_hook() happens.

Maybe it's possible to mark some modules to not become ro at all, I 
don't know. And doing so would make them a prefered target for exploits. 
So I'm not sure if it would make sense.

Regards,

Alexander Holler
Rabin Vincent April 1, 2014, 11:21 p.m. UTC | #4
2014-04-01 20:36 GMT+02:00 Kees Cook <keescook@chromium.org>:
> On Tue, Apr 1, 2014 at 11:03 AM, Laura Abbott <lauraa@codeaurora.org> wrote:
>> On 4/1/2014 3:04 AM, Alexander Holler wrote:
>>> CONFIG_DEBUG_SET_MODULE_RONX sounds like a nice security feature, but
>>> things might fail late (and unexpected) if module code is set to read-only
>>> while CONFIG_JUMP_LABEL is enabled (e.g. modprobe bridge).
>
> Isn't this a ordering problem? I thought jump labels got set up once,
> and then after that, the memory could be made RO?

The code gets patched every time the jump label is enabled/disabled,
i.e. every time the static_key is turned on/off based on
static_key_slow_{inc/dec}()
diff mbox

Patch

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 0531da8..6627b9e 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -1197,7 +1197,7 @@  config PID_IN_CONTEXTIDR
 
 config DEBUG_SET_MODULE_RONX
 	bool "Set loadable kernel module data as NX and text as RO"
-	depends on MODULES
+	depends on MODULES && !JUMP_LABEL
 	---help---
 	  This option helps catch unintended modifications to loadable
 	  kernel module's text and read-only data. It also prevents execution