From: jeffxu@chromium.org
To: dave.hansen@intel.com, luto@kernel.org, jorgelo@chromium.org,
keescook@chromium.org, groeck@chromium.org, jannh@google.com,
sroettger@google.com
Cc: akpm@linux-foundation.org, jeffxu@google.com,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
linux-mm@kvack.org, linux-hardening@vger.kernel.org
Subject: [PATCH 0/6] Memory Mapping (VMA) protection using PKU - set 1
Date: Mon, 15 May 2023 13:05:46 +0000 [thread overview]
Message-ID: <20230515130553.2311248-1-jeffxu@chromium.org> (raw)
From: Jeff Xu <jeffxu@google.com>
This is the first set of Memory mapping (VMA) protection patches using PKU.
* * *
Background:
As discussed previously in the kernel mailing list [1], V8 CFI [2] uses
PKU to protect memory, and Stephen Röttger proposes to extend the PKU to
memory mapping [3].
We're using PKU for in-process isolation to enforce control-flow integrity
for a JIT compiler. In our threat model, an attacker exploits a
vulnerability and has arbitrary read/write access to the whole process
space concurrently to other threads being executed. This attacker can
manipulate some arguments to syscalls from some threads.
Under such a powerful attack, we want to create a “safe/isolated”
thread environment. We assign dedicated PKUs to this thread,
and use those PKUs to protect the threads’ runtime environment.
The thread has exclusive access to its run-time memory. This
includes modifying the protection of the memory mapping, or
munmap the memory mapping after use. And the other threads
won’t be able to access the memory or modify the memory mapping
(VMA) belonging to the thread.
* * *
Proposed changes:
This patch introduces a new flag, PKEY_ENFORCE_API, to the pkey_alloc()
function. When a PKEY is created with this flag, it is enforced that any
thread that wants to make changes to the memory mapping (such as mprotect)
of the memory must have write access to the PKEY. PKEYs created without
this flag will continue to work as they do now, for backwards
compatibility.
Only PKEY created from user space can have the new flag set, the PKEY
allocated by the kernel internally will not have it. In other words,
ARCH_DEFAULT_PKEY(0) and execute_only_pkey won’t have this flag set,
and continue work as today.
This flag is checked only at syscall entry, such as mprotect/munmap in
this set of patches. It will not apply to other call paths. In other
words, if the kernel want to change attributes of VMA for some reasons,
the kernel is free to do that and not affected by this new flag.
This set of patch covers mprotect/munmap, I plan to work on other
syscalls after this.
* * *
Testing:
I have tested this patch on a Linux kernel 5.15, 6,1, and 6.4-rc1,
new selftest is added in: pkey_enforce_api.c
* * *
Discussion:
We believe that this patch provides a valuable security feature.
It allows us to create “safe/isolated” thread environments that are
protected from attackers with arbitrary read/write access to
the process space.
We believe that the interface change and the patch don't
introduce backwards compatibility risk.
We would like to disucss this patch in Linux kernel community
for feedback and support.
* * *
Reference:
[1]https://lore.kernel.org/all/202208221331.71C50A6F@keescook/
[2]https://docs.google.com/document/d/1O2jwK4dxI3nRcOJuPYkonhTkNQfbmwdvxQMyXgeaRHo/edit?usp=sharing
[3]https://docs.google.com/document/d/1qqVoVfRiF2nRylL3yjZyCQvzQaej1HRPh3f5wj1AS9I/edit
Best Regards,
-Jeff Xu
Jeff Xu (6):
PKEY: Introduce PKEY_ENFORCE_API flag
PKEY: Add arch_check_pkey_enforce_api()
PKEY: Apply PKEY_ENFORCE_API to mprotect
PKEY:selftest pkey_enforce_api for mprotect
KEY: Apply PKEY_ENFORCE_API to munmap
PKEY:selftest pkey_enforce_api for munmap
arch/powerpc/include/asm/pkeys.h | 19 +-
arch/x86/include/asm/mmu.h | 7 +
arch/x86/include/asm/pkeys.h | 92 +-
arch/x86/mm/pkeys.c | 2 +-
include/linux/mm.h | 2 +-
include/linux/pkeys.h | 18 +-
include/uapi/linux/mman.h | 5 +
mm/mmap.c | 34 +-
mm/mprotect.c | 31 +-
mm/mremap.c | 6 +-
tools/testing/selftests/mm/Makefile | 1 +
tools/testing/selftests/mm/pkey_enforce_api.c | 1312 +++++++++++++++++
12 files changed, 1507 insertions(+), 22 deletions(-)
create mode 100644 tools/testing/selftests/mm/pkey_enforce_api.c
base-commit: ba0ad6ed89fd5dada3b7b65ef2b08e95d449d4ab
--
2.40.1.606.ga4b1b128d6-goog
next reply other threads:[~2023-05-15 13:06 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-15 13:05 jeffxu [this message]
2023-05-15 13:05 ` [PATCH 1/6] PKEY: Introduce PKEY_ENFORCE_API flag jeffxu
2023-05-16 23:14 ` Dave Hansen
2023-05-16 23:55 ` Jeff Xu
2023-05-17 11:07 ` Stephen Röttger
2023-05-15 13:05 ` [PATCH 2/6] PKEY: Add arch_check_pkey_enforce_api() jeffxu
2023-05-18 21:43 ` Dave Hansen
2023-05-18 22:51 ` Jeff Xu
2023-05-19 0:00 ` Dave Hansen
2023-05-19 11:22 ` Stephen Röttger
2023-05-15 13:05 ` [PATCH 3/6] PKEY: Apply PKEY_ENFORCE_API to mprotect jeffxu
2023-05-16 20:07 ` Kees Cook
2023-05-16 22:23 ` Jeff Xu
2023-05-16 23:18 ` Dave Hansen
2023-05-16 23:36 ` Jeff Xu
2023-05-17 4:50 ` Jeff Xu
2023-05-15 13:05 ` [PATCH 4/6] PKEY:selftest pkey_enforce_api for mprotect jeffxu
2023-05-15 13:05 ` [PATCH 5/6] KEY: Apply PKEY_ENFORCE_API to munmap jeffxu
2023-05-16 20:06 ` Kees Cook
2023-05-16 22:24 ` Jeff Xu
2023-05-16 23:23 ` Dave Hansen
2023-05-17 0:08 ` Jeff Xu
2023-05-15 13:05 ` [PATCH 6/6] PKEY:selftest pkey_enforce_api for munmap jeffxu
2023-05-15 14:28 ` [PATCH 0/6] Memory Mapping (VMA) protection using PKU - set 1 Dave Hansen
2023-05-16 7:06 ` Stephen Röttger
2023-05-16 22:41 ` Dave Hansen
2023-05-17 10:51 ` Stephen Röttger
2023-05-17 15:07 ` Dave Hansen
2023-05-17 15:21 ` Jeff Xu
2023-05-17 15:29 ` Dave Hansen
2023-05-17 23:48 ` Jeff Xu
2023-05-18 15:37 ` Dave Hansen
2023-05-18 20:20 ` Jeff Xu
2023-05-18 21:04 ` Dave Hansen
2023-05-19 11:13 ` Stephen Röttger
2023-05-24 20:15 ` Jeff Xu
2023-06-01 1:39 ` Jeff Xu
2023-06-01 16:16 ` Dave Hansen
2023-05-31 23:02 ` Jeff Xu
2023-05-16 20:08 ` Kees Cook
2023-05-16 22:17 ` Jeff Xu
2023-05-16 22:30 ` Dave Hansen
2023-05-16 23:39 ` Jeff Xu
2023-05-17 10:49 ` Stephen Röttger
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=20230515130553.2311248-1-jeffxu@chromium.org \
--to=jeffxu@chromium.org \
--cc=akpm@linux-foundation.org \
--cc=dave.hansen@intel.com \
--cc=groeck@chromium.org \
--cc=jannh@google.com \
--cc=jeffxu@google.com \
--cc=jorgelo@chromium.org \
--cc=keescook@chromium.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=sroettger@google.com \
/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).