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 15D53C7EE29 for ; Fri, 19 May 2023 01:19:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3F9B7900004; Thu, 18 May 2023 21:19:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 382E4900003; Thu, 18 May 2023 21:19:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1FC89900004; Thu, 18 May 2023 21:19:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 0A7E2900003 for ; Thu, 18 May 2023 21:19:30 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id C528EA09C9 for ; Fri, 19 May 2023 01:19:29 +0000 (UTC) X-FDA: 80805246858.05.F474E30 Received: from mail-pl1-f178.google.com (mail-pl1-f178.google.com [209.85.214.178]) by imf08.hostedemail.com (Postfix) with ESMTP id DFAAB160019 for ; Fri, 19 May 2023 01:19:27 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=ZMW1ujm0; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf08.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.214.178 as permitted sender) smtp.mailfrom=jeffxu@chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684459168; 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: references:dkim-signature; bh=GjQ7lK8x1oL2I5FLMeKnNLIrlKblkTMw13nT3cZTNwk=; b=SgJe2HZT7Lw+Q8q1GgU3xw1DtMNNi1a5mUtxJtztELjGam92JiF5/QgGimHDOjm64291LS X1mRmwmh9Gk+QHl4OLCI9Cl+iaH5My28FgpGBolC1Y7BbzGSww0ZiR1LGFZxNYHCMLZmhM jph2BNxlFpfPIPTVj+ZPf04860B1IHI= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=ZMW1ujm0; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf08.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.214.178 as permitted sender) smtp.mailfrom=jeffxu@chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684459168; a=rsa-sha256; cv=none; b=3DVZXnx2YhtFVMSQFB94HelFYze/04BSW15x328/4VBu37cgntX1b/d1n0N35ucHuPinjk ebigldlOwpFUUeXIkrZCPdnpTzLRRnT+tdWKteZ9yAC/Gb8u6wnUPXClrsJOkZ5cNBi+D9 7xH8MiZCRRkCm3DwG1ysfrQZhXEVURI= Received: by mail-pl1-f178.google.com with SMTP id d9443c01a7336-1ae54b623c2so24044215ad.3 for ; Thu, 18 May 2023 18:19:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1684459166; x=1687051166; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=GjQ7lK8x1oL2I5FLMeKnNLIrlKblkTMw13nT3cZTNwk=; b=ZMW1ujm0IGNY4HJVwAoezA3+fLyirNIeI5kZF43KvmeV0tNoxyX+O2S2JdzkpN852K qwo/z8/aQZ78rKRpB4A25ywXP0hUVPkkkPIL/MA9enCQ/vdpwKmPx0Am8kl+ts9BBL/F kWJ5nb+orKVuCwDB7UZg+kL2eN4Sx2jtWLjyc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684459166; x=1687051166; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=GjQ7lK8x1oL2I5FLMeKnNLIrlKblkTMw13nT3cZTNwk=; b=Emyu6NIQdIAon7qMUaScw3sHdzGeNhjnjXNAxf4tPDhRXhqzFZqe8xmVbX8aObXowa EDSc9Sw9Jq0nlkajgIt2cFM9LtR2fPVO4R9tQL20yC419VkovFx7FxmGpDq1duM7cm6N 8PT8Z8c6j6tCj9325Eln5Fs8SM0602/3sZpg6Hnt0zI+sbSui7Blai3PSsoZiGX0UrGZ KAkStyvEHFmyoeWE6i5aRco0MvcEAlpPDga/RU/spBeASJtRkhlkbOTUyP/JHunrYwVt 8CUlE7w47SggchG5bUmTVK/kLoCjf3/Fg7I00Cc4IEuaOWnjjhkDJVSunWB3/K+u1vrA 7/Tg== X-Gm-Message-State: AC+VfDxWRw2hvkuT/5NRz9Amkh5XfzqT2CbLWYCb1j1vnqddM7/MFQbO 9GiZmeIA+PAz0IG9THsf10jEHw== X-Google-Smtp-Source: ACHHUZ52jvk/GEcjXoEOI/KyFOvc57rvcKEvB+GgBuys5A2AaRwCx5rVtsr4rXoWnPmxj1vyw0YjsQ== X-Received: by 2002:a17:903:32c7:b0:1ac:43ea:7882 with SMTP id i7-20020a17090332c700b001ac43ea7882mr1271097plr.29.1684459166520; Thu, 18 May 2023 18:19:26 -0700 (PDT) Received: from localhost (183.43.230.35.bc.googleusercontent.com. [35.230.43.183]) by smtp.gmail.com with UTF8SMTPSA id j6-20020a170902c08600b001ac2be26340sm2075201pld.222.2023.05.18.18.19.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 18 May 2023 18:19:26 -0700 (PDT) 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 v1 0/6] Memory Mapping (VMA) protection using PKU - set 1 Date: Fri, 19 May 2023 01:19:08 +0000 Message-ID: <20230519011915.846407-1-jeffxu@chromium.org> X-Mailer: git-send-email 2.40.1.698.g37aff9b760-goog MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: DFAAB160019 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: zo57j7nysrwqmxitoka4e1joeuej9dtf X-HE-Tag: 1684459167-669810 X-HE-Meta: U2FsdGVkX18Pck9F4VhP7kdMfndyLSEfimkSIsLETwxDWp/nSTc2x4O4HG8TMtfafTACzOAdOahVMxr4Yu+6MSlpmT+vLabnkodXKTKLf0xVLnPuWZDXVhAX3BVFLFwfsOQUuAVjlsrCy2LlTgpNYJp3myM+FAgxXm6ZGTfEilxj5ngNH2dnGLHYPHc/vNSSlJB/+UxwGD7To1Td4jihdS7E+BfeNC2mWuDdu+UhiLumwb7yfUo3JYyKaFjFI3TNbNjKZWeDTkZG076WsJlJuLP8JUR7/Hd9IXoHxWu+EHQ1gKG1CB0LAOBEq916wcq2HAEXJ+7n+fKuIcrUmPVGlZi0kQ+EfTIte4vtNbflaRZRSJjhItz2H0JJHF+E/wYiQcIwYTkyhkPSR6hws51h2k0jSv5+8WvBN8tagCD5nsA/wLtVbLT3HRwwIWYBoMnrEW1KUtIjAS7W8g9EhtdsNPU1rUALie6TLAz4FF9bTdojSzSQxoc0Nw8szA7w+Ifarp2UF9bIRpAw3NjlEKu9HvedU4/8xavS8bPDODv6whBy4mvpk4WMcS1oQ1gggHisoT8gsEHkPlhmxc5/LyuU4ut7suZmo3hgNNyfjHQzP72fJ5qxVyp4Kv4cD0EHOUjBFQiGu8Ez0yO6ItWMOsYeL9VuYQB/MIH7TEzTrrvRPNtWgUfkblq7kIrkhZq+Ge+f9eFpvANooF3ALnI2j1jjRt7KwX+k/yGa5I/Dwc61E0k5nbYaqa+Lj3rBrVIqI04HNOKCBj7AdgqiZsgc4KZMl4K2DvmO3XvcxDTnLY9EoeStw485LJjToa+Z7F9rdRfFZogpUtlPkfj+dmeDcyVl9X2MLMmxaIriQ+/MUDOttLvyV89kmVwsjGgL/sStKvwx0XbCO6cayWiBPFCNHF5X4XR8cHc6V0LPBNvopWcqStrm+FmNA8YwJskoYygvNXIWdNscL33Q2+OOOlJHMTL FAFD/1aj xUiMGUWeYXWC7KiwJ5VP/jsXmoY2J34XjMS8h7DzuK+gAzTndYPYDcAVbYeWpvP9hq473PhByW5mJq/DfBGDJT5EwWxIff0nO8GMcy77WOv+d6hmjlbjMhb3paBXlQqVIuTvTgWZZICUVwZHpjGera9OPf62PFudpub4xo+Yv3x1crw/STkfCZzm6t8Lw5gyDMWRK9vPpiA5K+nnakG6ueAqC9DzqApyHxoQQliEFBlzouTpnQPH7qptX/PpgHt1nQ736qskNE4XUUiG/48P3sDiI0j1KFjHl6oaXKMMdfC2QtHKSfaU3Bzopl+wDMjJ3HEpD52vaqEvcNlzuPPx/B7VpbDze0T/ECQJXdJIVhWx/jLXk2BQRNeIQ6BuiiWoa1U7425wVNEJFIUn2Hx/vVRcUDOI2zLCosAbPuOCEDtynWwaAWs+QFntysTL3kABcz0VDwyBjiRGWMd5yD+ezG0KCXRxR1R9tPTCvXSwn+51MCYQCJmoefMt8tvTVlF3QIECx 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: From: Jeff Xu 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 * * * 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