Date:	Mon, 24 Mar 2014 12:30:08 +0000
From:	Dave Martin <Dave.Martin@....com>
To:	Laura Abbott <lauraa@...eaurora.org>
Cc:	Kees Cook <keescook@...omium.org>,
	Catalin Marinas <Catalin.Marinas@....com>,
	Will Deacon <Will.Deacon@....com>,
	Larry Bassel <lbassel@...eaurora.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	Russell King <linux@....linux.org.uk>,
	Nicolas Pitre <nico@...aro.org>,
	Ben Dooks <ben.dooks@...ethink.co.uk>,
	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>,
	"grant.likely@...aro.org" <grant.likely@...aro.org>,
	Jiang Liu <liuj97@...il.com>,
	Christoffer Dall <cdall@...columbia.edu>,
	Marc Zyngier <Marc.Zyngier@....com>,
	"rob.herring@...xeda.com" <rob.herring@...xeda.com>,
	Vitaly Andrianov <vitalya@...com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Simon Baatz <gmbnomis@...il.com>,
	Jonathan Austin <Jonathan.Austin@....com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Santosh Shilimkar <santosh.shilimkar@...com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 2/2] ARM: mm: keep rodata non-executable

On Sun, Mar 23, 2014 at 06:47:36PM +0000, Laura Abbott wrote:
> On 2/17/2014 4:34 AM, Dave Martin wrote:
> > On Fri, Feb 14, 2014 at 11:11:07AM -0800, Kees Cook wrote:
> >> On Fri, Feb 14, 2014 at 8:22 AM, Dave Martin <Dave.Martin@....com> wrote:
> >>> On Thu, Feb 13, 2014 at 05:04:10PM -0800, Kees Cook wrote:
> >>>> Introduce "CONFIG_DEBUG_RODATA" to mostly match the x86 config, though
> >>>> the behavior is different: it depends on STRICT_KERNMEM_PERMS, which
> >>>> sets rodata read-only (but executable), where as this option additionally
> >>>> splits rodata from the kernel text (resulting in potentially more memory
> >>>> lost to padding) and sets it non-executable as well. The end result is
> >>>> that on builds with CONFIG_DEBUG_RODATA=y (like x86) the rodata with be
> >>>> marked purely read-only.
> >>>
> >>> This triggers an Oops in kexec, because we have a block of code in .text
> >>> which is a template for generating baremetal code to relocate the new
> >>> kernel, and some literal words are written into it before copying.
> >>
> >> You're writing into the text area? I would imagine that
> >> CONFIG_ARM_KERNMEM_PERMS would break that. However, that's not the
> >> right place to be building code -- shouldn't the module area be used
> >> for that?
> >>

[...]
	
> FWIW, we've hit issues not just with kexec but kprobes as well. The same
> problems exist with this series:

[...]

> We had some functions that allowed the text to be temporarily made writable but something
> uniform for kexec would be useful as well (our kexec solution has been 'turn it off')

kexec doesn't rely on poking the kernel text: the fact that it does this
is just a side-effect of the way it is currently implemented.

I would like to fix it -- it's currently on my todo list, but I
consider it non-urgent.  depending on !KEXEC seems reasonable for
now.

People building a hardened system may choose do disable kexec for other
reasons, but that's a separate issue entirely.


kprobes is a different matter: getting it to work with strict permissions
is likely to be complex and costly.  kprobes is already unavoidably
complex and costly, so that is probably better viewed as a kprobes
problem to be solved later, rather than a strict permissions problem.


Cheers
---Dave
--
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