From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id AF35AC77B7A for ; Fri, 19 May 2023 01:22:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4BBCB900004; Thu, 18 May 2023 21:22:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 46C6A900003; Thu, 18 May 2023 21:22:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 33413900004; Thu, 18 May 2023 21:22:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 214C0900003 for ; Thu, 18 May 2023 21:22:04 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id D0EB21A09BA for ; Fri, 19 May 2023 01:22:03 +0000 (UTC) X-FDA: 80805253326.20.2D458E8 Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com [209.85.128.47]) by imf19.hostedemail.com (Postfix) with ESMTP id F30F31A000F for ; Fri, 19 May 2023 01:22:01 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=wEdgpcJ7; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf19.hostedemail.com: domain of jeffxu@google.com designates 209.85.128.47 as permitted sender) smtp.mailfrom=jeffxu@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684459322; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=UqVmcIUSI4Xw+jP09wSJXm4OiN2hCwHu9FnNFUiMdYo=; b=xolAML0NeJrIyymV7+StkVA0OosszyC1+Q2dt1wS9lffo7aK9P9v+CiawdXoQSDj4nQ8LT 8zZIFHg9vs73eYA+bjqVYehQfvdRFx7xnL2pHXOuAL/9VjmY5Cli2xkZgS1bxNGw/K2W9Q KfRbk1b9Y9C/sKKS0wzRm6g7ABOGIq0= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=wEdgpcJ7; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf19.hostedemail.com: domain of jeffxu@google.com designates 209.85.128.47 as permitted sender) smtp.mailfrom=jeffxu@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684459322; a=rsa-sha256; cv=none; b=UpI3yShjG6wlXlwJRuD4u5PHgnIbWb6PwnpFK7tXqct8Ul1LlJr9t2C1s52s5wU5vkk/bI W2wUWAJ5eZ5u8EMD2gb72+Azk50cklMvk3XvWA667IrBbIxdgokxjEM8s7UGxDhLOdtO/Q 1Z7nG2wBgySqO3vBDW9Ay6G/AcAG9kw= Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-3f5dbd8f677so15915e9.1 for ; Thu, 18 May 2023 18:22:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1684459320; x=1687051320; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=UqVmcIUSI4Xw+jP09wSJXm4OiN2hCwHu9FnNFUiMdYo=; b=wEdgpcJ7Dj3UtTNIU2HlM1dn84V1NZeOPc9e5NTTZ9Qn8Ec7oCYJok2TaVM4qFxyRM FbcmfZ9z2gaRNvuKFS2K8atqsFjmPb2UE2b0ugJLBPHiSjwFZgv5e6KPjpBEIq8m8afm XJHV0AN3KeoKo4bZoTm14Q1q8fo6IEKrrGU8fpXh6lu+6jeIuuAX/nECVHVPC9b3mlK3 ym1FsB2/o21Em8ybiFGt4mpC7RspE4ILcTv8bq64xXEA4gccNf8v5xfOp1bGvPOWJl0v iSuFttY/MFvWUYEG0bu9PDAsRNQXBKlE1hQDE8ckKFe8niEpj9AyfVYkSUuvzNuYMhZw Fbwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684459320; x=1687051320; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=UqVmcIUSI4Xw+jP09wSJXm4OiN2hCwHu9FnNFUiMdYo=; b=I5Ivi6Svh+ugJNY8K51+8EB306Q+vREWoCOcwBU5ZmD75uL2PeIfDW4Wcdgeup5TMX 9b9fLa0aLcejvpntVISIdgfNe71bszl8EGiSloPX4shMPR9an4P0h1/eDUV8dh0Q1C6P jrXdFL8kKz/wDLBhSkI7+EEuH6ITME8TPswJby8M/ZUtete8PJwt6VqVtD2UEmW48VLf ou9N3s5Nx8ZCjt8O4ewa6S0QnCrNvt0tJ4VKgRRHf+kYMkgESgiqNKIIslZz23fJaBpM qlXVUJOJLL9K88Zz7no99xHAx+Jf0YB9OmHmo6p/eykl97oibquptm3xQ5DE/o8ijAL2 oF2A== X-Gm-Message-State: AC+VfDw7WpJRDv+1NmcnOISxoZswdaGCO2Tc+wDdWzg6gPhYYU8S/TKx Y0BTv/B0cJ2glnYtmSBBOS07yuKQotx5oi/catK7Hw== X-Google-Smtp-Source: ACHHUZ7M3/IbFNzSZ64MwfOjccnIXsHjJKpFlglqiau7g+2UhDxPQvtvdYUvEozRiR7XUuS8QbUg7zk5NYucG8i726c= X-Received: by 2002:a05:600c:4994:b0:3f1:758c:dd23 with SMTP id h20-20020a05600c499400b003f1758cdd23mr89382wmp.7.1684459320145; Thu, 18 May 2023 18:22:00 -0700 (PDT) MIME-Version: 1.0 References: <20230519011915.846407-1-jeffxu@chromium.org> In-Reply-To: <20230519011915.846407-1-jeffxu@chromium.org> From: Jeff Xu Date: Thu, 18 May 2023 18:21:24 -0700 Message-ID: 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 X-Rspamd-Queue-Id: F30F31A000F X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 6ygjzym3e58tmhoqt6orn4cp83bkbrfp X-HE-Tag: 1684459321-720061 X-HE-Meta: U2FsdGVkX1/jLLMMSxw1yfrRmYIkaGYk/Sk1mZxHIqe2QQwBbgTfLrLydj8SPHDivzMDJ3hRaJT2YBvGrwtyarR89sLMfukfHBB1nJh92M8P0a0JepIm/FYTW8MQTpiIDhvrxHgDOphjQOLO4e6h6Fnoaz9nQ5fTrCEIRrlNHbrZEffYbSXAJoEBxo94gjnvclI4xymfeKW6+o2ETmQUH1EwzYKQqMbEs+HXkS/aYf7b+pfQwZJlwzfzH52pvAyIieVgxfZBgQplaVqapngWoY0142/S8kVjsR46qwIuBr1k1L+VyquLMSBh3/YI/NkPfNDdGt9uyJUWRXwDlSRTh9zyBWZZnPEpY627R+LxkmqPc9gzqAMKiJnSJvY6gYAsAiSanEb8UbWm3gwAbuglYSWq0Up8cM2Zb97hZX2Sk9w78nyqKeBZPEyRBNxA0+nDU5ImM/2WxeBHDLiuvtuEfaZG6X4xfTOculNyXE+S2AIfxG1lAMpX9fueIuuoGpAbAIlU3Za9rHD31AuSPKH4Pwg+Q3pmZXSYx3a3crvmwIJo/NbrB1H8AyV/cI3W332t6DHpjLVmWGAdi0gqBf3Y4x1ynHkVLwttusHiPYLZhvi0zbQv85GhnvRM9nQoNjP127EZkcIggP8zDEEmiXC4mIqUdtd9am9EjcywaSFrsWkJ1276ylZ7C8IQwmVXUn2kSTdD1xF6dtasKInOzB8qzELlRVVF5SA6NnwrV/0skqb43I2AJasmejeDT6W6cYIOsmCbxizBgfMXBZUzJBs/Q1Qd5/MBDwxRXtZPs2RbTgGXdsScge/GlaKbUJk3AlneRecqt9XS9ekFRFsVUXjB6H4gKaiY4PMyZFJeK+oAV4aTrHw7fL6esbkAf7Cpud8+BXLxOIv5+lKZOemRRROUjvjF0MBlQ8yuyg0jdW6Qc6Y108BQLMEP1BFxM0zIupwdpWW6HkACS3AUnIRh5Ul qnjHVcbp OYnmcS39ikSMoTekF7DzJVb+aSPEB6DPWUerArZpjqJhomGeQYR9b44X5H06VjB0c5q4pOlZWpDFXjHG+PpcqmelwReI84RImOjfpsEih8hws8bXlmjWbNI1QNWc3EL2mRcwM8nHZ6MoORTwF+mS+1G+npGllY262bqsfbGCAn53YEofmpTbt9/lIFeGz7x2nS2US8jv2c6AV4WfCSj3z88iESb/iuqBGBNZJTJqCQfFmxqdypepRZSa3bwVTAQzDyeUqeL/BVX/SP7JhVzhKewKub2LRpEW1oNDc0LCQy2YblxkwxicJp0uM33UmlecsgDkmp5Wv6BkeK9zARpLdDMbvOA/g7fbxgn7YEKEMLYlnfnhXicdBpTgTw4uUzLA5EXN3zjTBWCZJmYd8JZV7KpQD0YqUHNHe05DI X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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 wrote: > > From: Jeff Xu > > 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 >