linux-kernel - Re: [kernel-hardening] [PATCH] module: extend 'rodata=off' boot cmdline parameter to module mappings

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20161026044358.GY19531@linaro.org>
Date:   Wed, 26 Oct 2016 13:43:59 +0900
From:   AKASHI Takahiro <takahiro.akashi@...aro.org>
To:     Rusty Russell <rusty@...tcorp.com.au>, Jessica Yu <jeyu@...hat.com>
Cc:     Kees Cook <keescook@...omium.org>,
        "kernel-hardening@...ts.openwall.com" 
        <kernel-hardening@...ts.openwall.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [kernel-hardening] [PATCH] module: extend 'rodata=off' boot
 cmdline parameter to module mappings

Rusty, Jessica

On Wed, Oct 26, 2016 at 10:43:32AM +1030, Rusty Russell wrote:
> AKASHI Takahiro <takahiro.akashi@...aro.org> writes:
> > On Thu, Oct 20, 2016 at 01:48:15PM -0700, Kees Cook wrote:
> >> On Wed, Oct 19, 2016 at 11:24 PM, AKASHI Takahiro
> >> <takahiro.akashi@...aro.org> wrote:
> >> > The current "rodata=off" parameter disables read-only kernel mappings
> >> > under CONFIG_DEBUG_RODATA:
> >> >     commit d2aa1acad22f ("mm/init: Add 'rodata=off' boot cmdline parameter
> >> >     to disable read-only kernel mappings")
> >> >
> >> > This patch is a logical extension to module mappings ie. read-only mappings
> >> > at module loading can be disabled even if CONFIG_DEBUG_SET_MODULE_RONX
> >> > (mainly for debug use). Please note, however, that it only affects RO/RW
> >> > permissions, keeping NX set.
> 
> This patch looks good (except the minor issues noted by Kees); please CC
> the followup version to Jessica as new module maintainer.

I think that the new version (v2)[1] addresses Kees' comments already.

[1] http://lkml.iu.edu//hypermail/linux/kernel/1610.2/04163.html

Thanks,
-Takahiro AKASHI

> Thanks!
> Rusty.
> 
> >> >
> >> > This is the first step to make CONFIG_DEBUG_SET_MODULE_RONX mandatory
> >> > (always-on) in the future as CONFIG_DEBUG_RODATA on x86 and arm64.
> >> >
> >> > Suggested-by: Mark Rutland <mark.rutland@....com>
> >> > Signed-off-by: AKASHI Takahiro <takahiro.akashi@...aro.org>
> >> > Cc: Rusty Russell <rusty@...tcorp.com.au>
> >> > ---
> >> > v1:
> >> >   * remove RFC's "module_ronx=" and merge it with "rodata="
> >> >   * always keep NX set if CONFIG_SET_MODULE_RONX
> >> >
> >> >  include/linux/init.h |  3 ++-
> >> >  init/main.c          |  2 +-
> >> >  kernel/module.c      | 21 ++++++++++++++++++---
> >> >  3 files changed, 21 insertions(+), 5 deletions(-)
> >> >
> >> > diff --git a/include/linux/init.h b/include/linux/init.h
> >> > index e30104c..20aa2eb 100644
> >> > --- a/include/linux/init.h
> >> > +++ b/include/linux/init.h
> >> > @@ -126,7 +126,8 @@ void prepare_namespace(void);
> >> >  void __init load_default_modules(void);
> >> >  int __init init_rootfs(void);
> >> >
> >> > -#ifdef CONFIG_DEBUG_RODATA
> >> > +#if defined(CONFIG_DEBUG_RODATA) || defined(CONFIG_DEBUG_SET_MODULE_RONX)
> >> > +extern bool rodata_enabled;
> >> >  void mark_rodata_ro(void);
> >> >  #endif
> >> >
> >> > diff --git a/init/main.c b/init/main.c
> >> > index 2858be7..92db2f3 100644
> >> > --- a/init/main.c
> >> > +++ b/init/main.c
> >> > @@ -915,7 +915,7 @@ static int try_to_run_init_process(const char *init_filename)
> >> >  static noinline void __init kernel_init_freeable(void);
> >> >
> >> >  #ifdef CONFIG_DEBUG_RODATA
> >> > -static bool rodata_enabled = true;
> >> > +bool rodata_enabled = true;
> >> 
> >> Is there a mismatch here between the extern ifdef and the bool ifdef?
> >> I.e. shouldn't the ifdef here be || DEBUG_SET_MODULE_RONX too?
> >
> > Yes.
> >
> >> Also, can you mark this as __ro_after_init, since nothing changes it
> >> after the kernel command line is parsed?
> >
> > Yes, yes.
> >
> > Thanks,
> > -Takahiro AKASHI
> >
> >> Otherwise, this looks fine to me.
> >> 
> >> -Kees
> >> 
> >> 
> >> -- 
> >> Kees Cook
> >> Nexus Security