From: Rusty Russell <rusty@rustcorp.com.au>
To: Andi Kleen <andi@firstfloor.org>
Cc: Siarhei Liakh <sliakh.lkml@gmail.com>,
linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org,
linux-next@vger.kernel.org,
Arjan van de Ven <arjan@infradead.org>,
James Morris <jmorris@namei.org>,
Andrew Morton <akpm@linux-foundation.org>, Andi Kleen <ak@muc.de>,
Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Dave Jones <davej@redhat.com>
Subject: Re: [PATCH v8] RO/NX protection for loadable kernel modules
Date: Mon, 8 Feb 2010 12:15:31 +1030 [thread overview]
Message-ID: <201002081215.31527.rusty@rustcorp.com.au> (raw)
In-Reply-To: <873a1jdyrg.fsf@basil.nowhere.org>
On Wed, 3 Feb 2010 09:35:39 am Andi Kleen wrote:
> Siarhei Liakh <sliakh.lkml@gmail.com> writes:
>
> > 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:
>
> My current kernel has 52 modules loaded, most of them very small.
> Assuming the additional alignment of the data section cost two more
> pages on average (I think that's a good assumption), that's roughly
> 424KB of additional memory, plus associated runtime costs in increased
> TLB usage.
>
> What would I get for that if I applied the patch and enabled the option?
Strict RO/NX protection. But without the option enabled, the patch gives
best-effort protection, which is nice (for no additional space).
Cheers,
Rusty.
next prev parent reply other threads:[~2010-02-08 1:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-31 23:22 [PATCH v8] RO/NX protection for loadable kernel modules Siarhei Liakh
2010-02-01 1:39 ` Rusty Russell
2010-02-01 16:22 ` Siarhei Liakh
2010-02-02 23:05 ` Andi Kleen
2010-02-03 4:07 ` Siarhei Liakh
2010-02-08 1:45 ` Rusty Russell [this message]
2010-02-08 1:54 ` H. Peter Anvin
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=201002081215.31527.rusty@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=ak@muc.de \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=arjan@infradead.org \
--cc=davej@redhat.com \
--cc=hpa@zytor.com \
--cc=jmorris@namei.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=sfr@canb.auug.org.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.