Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp2016034rwd; Mon, 15 May 2023 06:17:56 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4CoYDxwoKtRvEZHvWwdLMRg2PS/1OgPMb3jAmIhvspb0zyt40JjNR7Vvs2hZunc+dEuByU X-Received: by 2002:a05:6808:f12:b0:396:ffa:1a78 with SMTP id m18-20020a0568080f1200b003960ffa1a78mr1351756oiw.35.1684156675829; Mon, 15 May 2023 06:17:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1684156675; cv=none; d=google.com; s=arc-20160816; b=rJ8NzjYVoWk11d4MqZw6Kd1oTvm9LJfJ8DhdI8DOX82dEUUY55Qk8u4+4BdzhKYplt wTWBQKqu1BXlUW4sMsxMM/WsT1rmTBmj4C4wDSJKytXGoDFvB04ombba/cXvLpgZYZU8 fqFNWOCXM/nQOvkWCV7oqLqvSQ6sDPsMeY/8ItGgYBVew8DJ/4eKI+rVL3cCjCnoYMUP KH90hdPuLZi9n/yfqe+gRTd0SwKzhw7jBgJnNiszbTmhSsekhkCK9VQaDItlnnNUnxze 2qxEcjEWHtzCB9q1ZgfTK0h2w1bpUSbzW6+G06kQ5H8I0ZWmJdggePgHuyGhVODoWbM4 nh5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=x8d5WHH7LCFe26MinsbsZnyby5kr64LG/XJK9V0WNKg=; b=Va4D9sMT/xoyH+s8nOiQBJwJUReQVylCDPU9XOtGKaybxQM9L9M/ciObwW9QN3JF1F SIqM0O46yXZPT2mAPSNR25Y9N+tB202xk5t2mm2aCHtUowcMl+vt/uuvRqcWA5y9IPqL X7YMrGXura4OASspGGLBwpREscLTD1N+CCDBJgcat5qQDDSOo1mVUxwQ2RCglK42K2hC IDbYwmKdBwhn5G89CbRLsnffGiHITTH0hq9pFMhoRRXjfEqgJANHv0yane3NzMjKI/nC /OrNLnJ277367uXxtyGIReoUKIYrwUgWVVxEHj861UFC+QP+7UrDN6MmgK1z0PMrQ66+ VSig== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=NaHgRv2b; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id v132-20020acade8a000000b0038e9d9e2f51si9855319oig.304.2023.05.15.06.17.42; Mon, 15 May 2023 06:17:55 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=NaHgRv2b; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242171AbjEONGq (ORCPT + 99 others); Mon, 15 May 2023 09:06:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52068 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242174AbjEONGc (ORCPT ); Mon, 15 May 2023 09:06:32 -0400 Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A624C2133 for ; Mon, 15 May 2023 06:06:02 -0700 (PDT) Received: by mail-pl1-x630.google.com with SMTP id d9443c01a7336-1aaef97652fso87517705ad.0 for ; Mon, 15 May 2023 06:06:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1684155960; x=1686747960; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=x8d5WHH7LCFe26MinsbsZnyby5kr64LG/XJK9V0WNKg=; b=NaHgRv2bUNBZrF0o+5C3FTpheRmJqZQFaOSP8QzMXPq7WqJETIhWEOKc2lqj4Nm5T5 a32pCCSQx3QIgMU9tHmNWc24LCETh4+iOmKh8vrKudEVT2S+1tbvRWw9LG+/FQnfDIYd tKTg4DVijbBMGL0PW9Mno6mGxd/JJ4F4NkV9M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684155960; x=1686747960; 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=x8d5WHH7LCFe26MinsbsZnyby5kr64LG/XJK9V0WNKg=; b=GSkd25jaItyCPbbOKdqstOtLt0JoGtNlLsgaKlF376Q7/5ynNcnBj0T2nw4SnghlWq QX30FeEkBoZrQyRgWFuT8APRKdSl+1Ezt8xRm8c8uoOATJpqbJjDssVods4USOeEKgL9 KZ9sBCU8NkhITPAhkf6Mx49ZtN2B3P1fX6c2Lq0MoCazJfEyR/Sxh753Cb795oohtXyI mZXNZWeLw3LCZ0+RCgVDiZIldMx5ynhZuNAdxXeflwnSmmyNLusE7dE39fpPQ0wJVgUY JXaUkEbGkYTVuSoPlXdD+1h/CXlw8Ci4IzX4lfqo5zdReewNnzMmktxbfBxy99gIL+yX jK0A== X-Gm-Message-State: AC+VfDycD6W876RXJgMx+Dh8kWNeURG2K/TcWsHy1zDZUxYXHKkVFYkJ VjEwzuhST5KDmZXc2vCxS42+Hw== X-Received: by 2002:a17:902:dace:b0:1ac:6e1f:d1bd with SMTP id q14-20020a170902dace00b001ac6e1fd1bdmr37375631plx.19.1684155960357; Mon, 15 May 2023 06:06:00 -0700 (PDT) Received: from localhost (183.43.230.35.bc.googleusercontent.com. [35.230.43.183]) by smtp.gmail.com with UTF8SMTPSA id ji1-20020a170903324100b001a9b7584824sm13461277plb.159.2023.05.15.06.05.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 15 May 2023 06:05:59 -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 0/6] Memory Mapping (VMA) protection using PKU - set 1 Date: Mon, 15 May 2023 13:05:46 +0000 Message-ID: <20230515130553.2311248-1-jeffxu@chromium.org> X-Mailer: git-send-email 2.40.1.606.ga4b1b128d6-goog MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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