[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090629083051.232bac68@infradead.org>
Date: Mon, 29 Jun 2009 08:30:51 -0700
From: Arjan van de Ven <arjan@...radead.org>
To: Siarhei Liakh <sliakh.lkml@...il.com>
Cc: James Morris <jmorris@...ei.org>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org,
linux-security-module@...r.kernel.org, Andi Kleen <ak@....de>,
Rusty Russell <rusty@...tcorp.com.au>,
Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH v2] RO/NX protection for loadable kernel modules
On Mon, 29 Jun 2009 11:16:40 -0400
Siarhei Liakh <sliakh.lkml@...il.com> wrote:
> This patch is a logical extension of the protection provided by
> CONFIG_DEBUG_RODATA to LKMs. The protection is provided by splitting
> module_core and module_init into three logical parts each and setting
> appropriate page access permissions for each individual section:
>
> 1. Code: RO+X
> 2. RO data: RO+NX
> 3. RW data: RW+NX
>
> In order to achieve proper protection, layout_sections() have been
> modified to align each of the three parts mentioned above onto page
> boundary. Next, the corresponding page access permissions are set
> right before successful exit from load_module(). Further,
> module_free() have been modified to set module_core or module_init as
> RW+NX right before calling vfree(). Functionality of this patch is
> enabled only when CONFIG_DEBUG_RODATA defined at compile time.
>
> This is the second revision of the patch: it have been re-written to
> reduce the number of #ifdefs and to make it architecture-agnostic.
> Code formatting have been corrected also.
>
you can still go one step further....
there is no downside to doing NX at all for modules, except for the 3
sections now each being page aligned thing. So in principle NX should
just not be part of any ifdef, only the alignment has any justification
for being so.
What you can do in the !CONFIG_OPTION case, is treating the "overlap"
pages as "most permissive goes"..... if you do that you should have 1
ifdef in total.
(and one can still argue that making this an option is not even worth
that, and just always do it unconditional)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists