mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Arjan van de Ven <arjan@infradead.org>
To: Siarhei Liakh <sliakh.lkml@gmail.com>
Cc: James Morris <jmorris@namei.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org, Andi Kleen <ak@muc.de>,
	Rusty Russell <rusty@rustcorp.com.au>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH v2] RO/NX protection for loadable kernel modules
Date: Mon, 29 Jun 2009 08:30:51 -0700	[thread overview]
Message-ID: <20090629083051.232bac68@infradead.org> (raw)
In-Reply-To: <817ecb6f0906290816t2537e5des3b78b32c6fd16700@mail.gmail.com>

On Mon, 29 Jun 2009 11:16:40 -0400
Siarhei Liakh <sliakh.lkml@gmail.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)

  reply	other threads:[~2009-06-29 15:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-29 15:16 Siarhei Liakh
2009-06-29 15:30 ` Arjan van de Ven [this message]
2009-06-29 19:54   ` Ingo Molnar
2009-06-30 13:11   ` Siarhei Liakh
2009-06-30 13:29     ` Arjan van de Ven
2009-06-30 14:44       ` Siarhei Liakh
2009-07-01  4:58         ` Arjan van de Ven

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090629083051.232bac68@infradead.org \
    --to=arjan@infradead.org \
    --cc=ak@muc.de \
    --cc=akpm@linux-foundation.org \
    --cc=hpa@zytor.com \
    --cc=jmorris@namei.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rusty@rustcorp.com.au \
    --cc=sliakh.lkml@gmail.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®