Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 2 Mar 2017 11:19:21 +0000
From: Mark Rutland <mark.rutland@....com>
To: Andy Lutomirski <luto@...capital.net>
Cc: Kees Cook <keescook@...omium.org>, Hoeun Ryu <hoeun.ryu@...il.com>,
	"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>,
	Andy Lutomirski <luto@...nel.org>, PaX Team <pageexec@...email.hu>,
	Emese Revfy <re.emese@...il.com>,
	Russell King <linux@...linux.org.uk>,
	"x86@...nel.org" <x86@...nel.org>
Subject: Re: [RFC][PATCH 1/8] Introduce rare_write() infrastructure

On Wed, Mar 01, 2017 at 01:00:05PM -0800, Andy Lutomirski wrote:
> On Wed, Mar 1, 2017 at 12:13 PM, Kees Cook <keescook@...omium.org> wrote:
> > On Wed, Mar 1, 2017 at 2:43 AM, Mark Rutland <mark.rutland@....com> wrote:
> >> The RW alias write_write(var, val) approach only relies on what arches
> >> already have to implement for userspace to work, so if we can figure out
> >> how to make that work API-wise, we can probably implement that
> >> generically with switch_mm() and {get,put}_user().
> >
> > With a third mm? I maybe misunderstood what you meant about userspace...
> 
> I think I'd like this series a lot better if the arch hooks were
> designed in such a way that a generic implementation could be backed
> by kmap, use_mm, or similar.  This would *require* that the arch hooks
> be able to return a different address.  Also, I see no reason that the
> list manipulation needs to be particularly special.  If the arch hook
> sets up an alias, couldn't the generic code just call it twice.

I completely agree.

There's some fun to be had with switch_mm/use_mm (e.g. with arm64's
TTBR0_SW_PAN), but I think we can solve that generically.

> So here's a new proposal for how the hooks could look:

> void __arch_rare_write_begin(void);
> void __arch_rare_write(void *dest, const void *source, size_t len);
> void __arch_rare_write_end(void);

I think we're on the same page, API-wise.

Modulo naming, and the len argument to the write function, this is
exactly the same as my original proposal.

I had assumed that we could derive the len argument implicitly from the
object being assigned to, but it doesn't really matter either way.

> Now a generic implementation could work by allocating a percpu
> mm_struct that contains a single giant VMA.  __arch_rare_write_begin()
> switches to that mm.  __arch_rare_write pokes some PTEs into the mm
> and calls copy_to_user().  __arch_rare_write_end() switches back to
> the original mm.  An x86 implementation could just fiddle with CR0.WP.

I'd expected that we'd know where the write_rarely data was up-front, so
we could set up the mapping statically, and just map it in at map/begin,
but otherwise this sounds like what I had in mind.

Thanks,
Mark.

Powered by blists - more mailing lists

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.