Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230519011915.846407-1-jeffxu@chromium.org>
In-Reply-To: <20230519011915.846407-1-jeffxu@chromium.org>
From:   Jeff Xu <jeffxu@google.com>
Date:   Thu, 18 May 2023 18:21:24 -0700
Message-ID: <CALmYWFvk8mbx4JSddRnHVZ0EmeZKKA7gKMa2zsVkJ4GWcCMcLw@mail.gmail.com>
Subject: Re: [PATCH v1 0/6] Memory Mapping (VMA) protection using PKU - set 1
To:     jeffxu@chromium.org
Cc:     dave.hansen@intel.com, luto@kernel.org, jorgelo@chromium.org,
        keescook@chromium.org, groeck@chromium.org, jannh@google.com,
        sroettger@google.com, akpm@linux-foundation.org,
        linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
        linux-mm@kvack.org, linux-hardening@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

This is updating code comments from v0.
There are on-going discussions related to threat-model and io_uring
which we can use the V0 thread.

On Thu, May 18, 2023 at 6:19=E2=80=AFPM <jeffxu@chromium.org> wrote:
>
> From: Jeff Xu <jeffxu@google.com>
>
> This is the first set of Memory mapping (VMA) protection patches using PK=
U.
>
> * * *
>
> Background:
>
> As discussed previously in the kernel mailing list [1], V8 CFI [2] uses
> PKU to protect memory, and Stephen R=C3=B6ttger proposes to extend the PK=
U to
> memory mapping [3].
>
> We're using PKU for in-process isolation to enforce control-flow integrit=
y
> 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 =E2=80=9Csafe/isolated=
=E2=80=9D
> thread environment. We assign dedicated PKUs to this thread,
> and use those PKUs to protect the threads=E2=80=99 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=E2=80=99t 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=E2=80=99t have this flag s=
et,
> 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 =E2=80=9Csafe/isolated=E2=80=9D thread environment=
s 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/1O2jwK4dxI3nRcOJuPYkonhTkNQfbmwdvxQ=
MyXgeaRHo/edit?usp=3Dsharing
> [3]https://docs.google.com/document/d/1qqVoVfRiF2nRylL3yjZyCQvzQaej1HRPh3=
f5wj1AS9I/edit
>
> * * *
> Current status:
>
> There are on-going discussion related to threat model, io_uring, we will =
continue discuss using v0 thread.
>
> * * *
> PATCH history:
>
> v1: update code related review comments:
> mprotect.c:
>         remove syscall from do_mprotect_pkey()
>         remove pr_warn_ratelimited
>
> munmap.c:
>         change syscall to enum caller_origin
>         remove pr_warn_ratelimited
>
> v0:
> https://lore.kernel.org/linux-mm/20230515130553.2311248-1-jeffxu@chromium=
.org/
>
> 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
>   PKEY: 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                            |    8 +-
>  include/linux/pkeys.h                         |   18 +-
>  include/uapi/linux/mman.h                     |    5 +
>  mm/mmap.c                                     |   31 +-
>  mm/mprotect.c                                 |   17 +-
>  mm/mremap.c                                   |    6 +-
>  tools/testing/selftests/mm/Makefile           |    1 +
>  tools/testing/selftests/mm/pkey_enforce_api.c | 1312 +++++++++++++++++
>  12 files changed, 1499 insertions(+), 19 deletions(-)
>  create mode 100644 tools/testing/selftests/mm/pkey_enforce_api.c
>
>
> base-commit: ba0ad6ed89fd5dada3b7b65ef2b08e95d449d4ab
> --
> 2.40.1.606.ga4b1b128d6-goog
>