From: Dave Hansen <dave@sr71.net>
To: dave@sr71.net
Cc: linux-kernel@vger.kernel.org, x86@kernel.org
Subject: [PATCH 09/12] x86, pkeys: notify userspace about protection key faults
Date: Thu, 07 May 2015 10:41:36 -0700 [thread overview]
Message-ID: <20150507174136.DD696F6F@viggo.jf.intel.com> (raw)
In-Reply-To: <20150507174132.34AF8FAF@viggo.jf.intel.com>
A protection key fault is very similar to any other access
error. There must be a VMA, etc... We even want to take
the same action (SIGSEGV) that we do with a normal access
fault.
However, we do need to let userspace know that something
is different. We do this the same way what we did with
SEGV_BNDERR with Memory Protection eXtensions (MPX):
define a new SEGV code: SEGV_PKUERR.
We will, at some point need to allow userspace a way to
figure out which protection key coveres the address that
we faulted on. We can either do that with a separate
interface, or we could pass it up in the siginfo like
MPX did.
Suggestions welcome. :)
---
b/arch/x86/mm/fault.c | 5 ++++-
b/include/uapi/asm-generic/siginfo.h | 10 +++++++++-
2 files changed, 13 insertions(+), 2 deletions(-)
diff -puN arch/x86/mm/fault.c~pkeys-13-siginfo arch/x86/mm/fault.c
--- a/arch/x86/mm/fault.c~pkeys-13-siginfo 2015-05-07 10:31:44.169312893 -0700
+++ b/arch/x86/mm/fault.c 2015-05-07 10:31:44.174313118 -0700
@@ -838,7 +838,10 @@ static noinline void
bad_area_access_error(struct pt_regs *regs, unsigned long error_code,
unsigned long address)
{
- __bad_area(regs, error_code, address, SEGV_ACCERR);
+ if (error_code & PF_PK)
+ __bad_area(regs, error_code, address, SEGV_PKUERR);
+ else
+ __bad_area(regs, error_code, address, SEGV_ACCERR);
}
static void
diff -puN include/uapi/asm-generic/siginfo.h~pkeys-13-siginfo include/uapi/asm-generic/siginfo.h
--- a/include/uapi/asm-generic/siginfo.h~pkeys-13-siginfo 2015-05-07 10:31:44.170312938 -0700
+++ b/include/uapi/asm-generic/siginfo.h 2015-05-07 10:31:44.174313118 -0700
@@ -95,6 +95,13 @@ typedef struct siginfo {
void __user *_lower;
void __user *_upper;
} _addr_bnd;
+ int protection_key; /* FIXME: protection key value??
+ * Do we really need this in here?
+ * userspace can get the PKRU value in
+ * the signal handler, but they do not
+ * easily have access to the PKEY value
+ * from the PTE.
+ */
} _sigfault;
/* SIGPOLL */
@@ -206,7 +213,8 @@ typedef struct siginfo {
#define SEGV_MAPERR (__SI_FAULT|1) /* address not mapped to object */
#define SEGV_ACCERR (__SI_FAULT|2) /* invalid permissions for mapped object */
#define SEGV_BNDERR (__SI_FAULT|3) /* failed address bound checks */
-#define NSIGSEGV 3
+#define SEGV_PKUERR (__SI_FAULT|4) /* failed address bound checks */
+#define NSIGSEGV 4
/*
* SIGBUS si_codes
_
next prev parent reply other threads:[~2015-05-07 17:44 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-07 17:41 [PATCH 00/12] [RFC] x86: Memory Protection Keys Dave Hansen
2015-05-07 17:41 ` [PATCH 01/12] x86, pkeys: cpuid bit definition Dave Hansen
2015-05-07 17:41 ` [PATCH 02/12] x86, pku: define new CR4 bit Dave Hansen
2015-05-07 17:41 ` [PATCH 06/12] x86, pkeys: store protection in high VMA flags Dave Hansen
2015-05-15 21:10 ` Thomas Gleixner
2015-05-15 21:13 ` Dave Hansen
2015-05-07 17:41 ` [PATCH 03/12] x86, pkey: pkru xsave fields and data structure Dave Hansen
2015-05-07 17:41 ` [PATCH 05/12] x86, pkeys: new page fault error code bit: PF_PK Dave Hansen
2015-05-07 17:41 ` [PATCH 04/12] x86, pkeys: PTE bits Dave Hansen
2015-05-07 17:41 ` [PATCH 08/12] x86, pkeys: arch-specific protection bits Dave Hansen
2015-05-07 17:41 ` [PATCH 07/12] mm: Pass the 4-bit protection key in via PROT_ bits to syscalls Dave Hansen
2015-05-07 19:11 ` One Thousand Gnomes
2015-05-07 19:19 ` Dave Hansen
2015-09-04 20:13 ` Florian Weimer
2015-09-04 20:18 ` Dave Hansen
2015-09-04 20:34 ` Florian Weimer
2015-09-04 20:41 ` Dave Hansen
2015-05-07 17:41 ` [PATCH 11/12] x86, pkeys: actually enable Memory Protection Keys in CPU Dave Hansen
2015-05-07 17:41 ` [PATCH 10/12] x86, pkeys: differentiate Protection Key faults from normal Dave Hansen
2015-05-07 17:41 ` [PATCH 12/12] x86, pkeys: Documentation Dave Hansen
2015-05-07 17:41 ` Dave Hansen [this message]
2015-05-07 17:57 ` [PATCH 00/12] [RFC] x86: Memory Protection Keys Ingo Molnar
2015-05-07 18:09 ` Dave Hansen
2015-05-07 18:48 ` Vlastimil Babka
2015-05-07 21:45 ` Dave Hansen
2015-05-09 19:09 ` Dr. David Alan Gilbert
2015-05-07 19:18 ` One Thousand Gnomes
2015-05-07 19:26 ` Ingo Molnar
2015-05-07 19:40 ` Dave Hansen
2015-05-07 20:11 ` One Thousand Gnomes
2015-05-08 4:51 ` Ingo Molnar
2015-05-08 6:09 ` Kevin Easton
2015-05-07 19:22 ` Christian Borntraeger
2015-05-07 19:29 ` Dave Hansen
2015-05-07 19:45 ` Christian Borntraeger
2015-05-07 19:49 ` Dave Hansen
2015-05-07 19:57 ` Christian Borntraeger
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=20150507174136.DD696F6F@viggo.jf.intel.com \
--to=dave@sr71.net \
--cc=linux-kernel@vger.kernel.org \
--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.