linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/3] arm64: dump: Add checking for writable and exectuable pages
Date: Fri, 30 Sep 2016 17:41:48 +0100	[thread overview]
Message-ID: <20160930164147.GD1729@remoulade> (raw)
In-Reply-To: <CAGXu5jJHohnRBxQAY-S7_iccgjc6xNUdBGb67b1-cOATyO-q0A@mail.gmail.com>

On Fri, Sep 30, 2016 at 09:25:45AM -0700, Kees Cook wrote:
> On Fri, Sep 30, 2016 at 8:58 AM, Mark Rutland <mark.rutland@arm.com> wrote:

> > Would it be worth verifying that all kernel mappings are UXN, too?
> >
> > ARMv8 allows execute-only mappings, and a !UXN mapping could result in an info
> > leak (e.g. pointers in MOVZ+MOVK sequences), or potential asynchronous issues
> > (e.g. user instruction fetches accessing read-destructive device registers).
> > All kernel mappings *should* be UXN.
> 
> I love this idea, but based on what came up with hardened usercopy,
> there are a lot of readers of kernel memory still. I think the
> expectations around UXN need to be clarified so we can reason about
> things like perf that want to read the kernel text.

The UXN (User eXecute Never) bit only controls whether userspace can execute a
page, not whether the kernel can read it. The RW permissions come from the AP
bits regardless.

We already try to ensure that all kernel memory is UXN by construction, so this
would just be a sanity check, as with the rest of the W^X checks.

The MOVZ+MOVK case above is where a sequence of 16-bit immediate MOVs are used
to encode a pointer. If a kernel mapping lacked UXN, userspace could execute it
(unprivileged), and extract the pointer generated into a GPR.

Having kernel exec-only memory is a different story entirely, though I agree
it's something to look into.

Thanks,
Mark

  reply	other threads:[~2016-09-30 16:41 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-29 21:32 [PATCH 0/3] WX Checking for arm64 Laura Abbott
2016-09-29 21:32 ` [PATCH 1/3] arm64: dump: Make ptdump debugfs a separate option Laura Abbott
2016-09-30  0:13   ` Mark Rutland
2016-09-30  0:31     ` Laura Abbott
2016-09-30  0:48       ` Mark Rutland
2016-09-30  1:11         ` Laura Abbott
2016-09-30  1:27           ` Mark Rutland
2016-09-29 21:32 ` [PATCH 2/3] arm64: dump: Make the page table dumping seq_file optional Laura Abbott
2016-09-30  0:36   ` Mark Rutland
2016-09-29 21:32 ` [PATCH 3/3] arm64: dump: Add checking for writable and exectuable pages Laura Abbott
2016-09-30  2:08   ` Mark Rutland
2016-09-30 15:58   ` Mark Rutland
2016-09-30 16:25     ` Kees Cook
2016-09-30 16:41       ` Mark Rutland [this message]
2016-09-30 17:16         ` Kees Cook
2016-09-30  1:29 ` [kernel-hardening] [PATCH 0/3] WX Checking for arm64 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=20160930164147.GD1729@remoulade \
    --to=mark.rutland@arm.com \
    --cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).