All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Kees Cook <keescook@chromium.org>
Cc: Andy Lutomirski <luto@amacapital.net>,
	"kernel-hardening@lists.openwall.com"
	<kernel-hardening@lists.openwall.com>,
	Andy Lutomirski <luto@kernel.org>,
	Hoeun Ryu <hoeun.ryu@gmail.com>, PaX Team <pageexec@freemail.hu>,
	Emese Revfy <re.emese@gmail.com>,
	Russell King <linux@armlinux.org.uk>, X86 ML <x86@kernel.org>
Subject: [kernel-hardening] Re: [RFC][PATCH 4/8] x86: Implement __arch_rare_write_map/unmap()
Date: Thu, 2 Mar 2017 11:20:32 +0000	[thread overview]
Message-ID: <20170302112032.GC19632@leverpostej> (raw)
In-Reply-To: <CAGXu5jKVANfBQVf66c=bJO7kRPhc7Q++L6pQk5m+6TLWm_gw8g@mail.gmail.com>

On Wed, Mar 01, 2017 at 12:25:11PM -0800, Kees Cook wrote:
> On Wed, Mar 1, 2017 at 3:24 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> > There is no global override of this sort on arm64. Just having map/unap,
> > open/close, shed/unshed, etc, won't work.
> >
> > The options I can think of for arm64 are:
> >
> > * Have a separate RW alias of just the write_rarely data, that we
> >   temporarily map-in on a given CPU (using TTBR0) to perform the write.
> >   The RW alias is at a different VA to the usual RO alias, so we have to
> >   convert each pointer to its RW alias to perform the write. That's why
> >   we need __rare_write_ptr() to hide this, and can't have uninstrumented
> >   writes.
> 
> I think only the list code isn't instrumented, and that's just because
> it discards casts outside the function. There's no reason it couldn't
> be instrumented. 

Ok, it sounds like we could make this work, then.

> >   Since this would *only* map the write_rarely data, it's simple to set
> >   up, and we don't need to modify the tables at runtime.
> >
> >   I also think we can implement this generically using switch_mm() and
> >   {get,put}_user(), or specialised variants thereof.
> >
> >   Assuming we can figure out how to handle those complex cases, this is
> >   my preferred solution. :)
> 
> Would this alias be CPU-local? (I assume yes, given the "give up on on
> being per-cpu" option below..)

Yes, this would be CPU-local. It would be like mapping the idmap, or
userspace.

Thanks,
Mark.

  reply	other threads:[~2017-03-02 11:20 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-27 20:42 [kernel-hardening] [RFC] Introduce rare_write() infrastructure Kees Cook
2017-02-27 20:42 ` [kernel-hardening] [RFC][PATCH 1/8] " Kees Cook
2017-02-28  8:22   ` [kernel-hardening] " Hoeun Ryu
2017-02-28 15:05     ` Kees Cook
2017-03-01 10:43       ` Mark Rutland
2017-03-01 20:13         ` Kees Cook
2017-03-01 20:31           ` Kees Cook
2017-03-01 21:00           ` Andy Lutomirski
2017-03-01 23:14             ` Kees Cook
2017-03-02 11:19             ` Mark Rutland
2017-03-02 16:33               ` Andy Lutomirski
2017-03-02 19:48                 ` Kees Cook
2017-02-27 20:43 ` [kernel-hardening] [RFC][PATCH 2/8] lkdtm: add test for " Kees Cook
2017-02-27 20:43 ` [kernel-hardening] [RFC][PATCH 3/8] net: switch sock_diag handlers to rare_write() Kees Cook
2017-02-27 20:43 ` [kernel-hardening] [RFC][PATCH 4/8] x86: Implement __arch_rare_write_map/unmap() Kees Cook
2017-02-28 19:33   ` [kernel-hardening] " Andy Lutomirski
2017-02-28 21:35     ` Kees Cook
2017-02-28 22:54       ` Andy Lutomirski
2017-02-28 23:52         ` Kees Cook
2017-03-01 11:24           ` Mark Rutland
2017-03-01 20:25             ` Kees Cook
2017-03-02 11:20               ` Mark Rutland [this message]
2017-03-03  0:59             ` Hoeun Ryu
2017-03-01 10:59       ` Mark Rutland
2017-02-27 20:43 ` [kernel-hardening] [RFC][PATCH 5/8] ARM: " Kees Cook
2017-03-01  1:04   ` [kernel-hardening] " Russell King - ARM Linux
2017-03-01  5:41     ` Kees Cook
2017-03-01 11:30       ` Russell King - ARM Linux
2017-03-02  0:08         ` Kees Cook
2017-03-01 11:50       ` Mark Rutland
2017-02-27 20:43 ` [kernel-hardening] [RFC][PATCH 6/8] list: add rare_write() list helpers Kees Cook
2017-02-27 20:43 ` [kernel-hardening] [RFC][PATCH 7/8] gcc-plugins: Add constify plugin Kees Cook
2017-02-27 20:43 ` [kernel-hardening] [RFC][PATCH 8/8] cgroups: force all struct cftype const Kees Cook

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=20170302112032.GC19632@leverpostej \
    --to=mark.rutland@arm.com \
    --cc=hoeun.ryu@gmail.com \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux@armlinux.org.uk \
    --cc=luto@amacapital.net \
    --cc=luto@kernel.org \
    --cc=pageexec@freemail.hu \
    --cc=re.emese@gmail.com \
    --cc=x86@kernel.org \
    /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.