Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp245185pxb; Thu, 21 Apr 2022 23:02:00 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyaL0I4EmtXzvyT1JwVayUPMRsaegJSrY9FXEidPvIUSfUQCvTBU19kLFaB0zZNmwh9Pu67 X-Received: by 2002:a63:ed45:0:b0:399:5116:312a with SMTP id m5-20020a63ed45000000b003995116312amr2492818pgk.611.1650607319966; Thu, 21 Apr 2022 23:01:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650607319; cv=none; d=google.com; s=arc-20160816; b=MGbaFsjrWy9CEpZv+LTAuVknUaXjRXH0CyC3tZA9tIcHAbgvwDOkgXQZsjA9kYPaQD /sl1zj1CHuA5gKn0oBXyj/KhZE9ScSBxufdxjR9UakSsb9TS0oZOBnumlJIri+cGlpjd xjG6jKzfZsKaAIuQSbDEjFumDnvaa/IMgZ7ztrE7T4I8e/h1UTYSqlSiKeFHUgQ3NUrr 1bz2kz010IQupERdqnyz7hEhBcHPd0E11lTRKjyT2XU0dj5rA17FbXVwrFhoucXafqnG vgv4CK0G3uoVQEnpkeC0ET8uDdG+Q8MGjSZpr1Z+FZMjg5FZkdt9zfemOC50DXg9mlZT jDSA== 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 :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=+WZvvGQdokaMvN5v4yLJ5TjhYM2clG9wx2jrTGp1gnk=; b=grK3Gj0ye3/2nnX1SHkULZTA5GE+d0sBmMnZ7jW1UBNZwn7/6UN/H/g7meQRXOy7t8 v/3mBN3AQ4YlRNntAUPcmxYiOMN9N4LIm6U6L9959ljvP0tlZlncTu4f5FwvRcjrCuK8 xsjX9DfacrlTBXBlieWusMUAQp7C1qEZ6Qlm7M7+0k0PowC4hWO68X2lNX7CYnY1a2EW 6jyjOQkPdOWbGwSoo333Xogmb4fYKCDGFRqgvgioxfWZidDnqeUm7RHvB38t2PQjZJaO Kpxnf6zEe57px1U5BKwuEUETu+KaQFMloPqq8129Xp+4HyELrTBHhafsk6JnInOuelOF 5d1g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=JWymLZw2; 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=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id a192-20020a6390c9000000b003aa6d422fd2si5975277pge.57.2022.04.21.23.01.46; Thu, 21 Apr 2022 23:01:59 -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=@intel.com header.s=Intel header.b=JWymLZw2; 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=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1355915AbiDSRLQ (ORCPT + 99 others); Tue, 19 Apr 2022 13:11:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59842 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1355658AbiDSRJ5 (ORCPT ); Tue, 19 Apr 2022 13:09:57 -0400 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 33E33DED9 for ; Tue, 19 Apr 2022 10:07:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1650388034; x=1681924034; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=Ql2r7AqKnHApM/EHR/Pff0tcNQI0JekmA3IUxRweYz0=; b=JWymLZw2iN/fu/UnU9KDK1Ev49ZQ0YD22Nx4Yy9+nFJFLuZaeNU7ikFq LTIyZ+rFp5K5dBfQaUDv5QM8nyEtQ/qr/qelwVpsIFsWlyxLvbq+zvBDV 7D7KFX1dZvEZJ4qPHR1yY1KzIZuAIyg+ichRv4OgYOfP9v1Shx6XDyWmr VbT1MjJiyApB36ZQjKYO7l9qc6tOX+2Q/tCDTT2Q8iidwcZautNB8hDzw Jqng7ncuIhEC0d8apjUz+6DSRGc5L9J1nYGEGwyn3T0L8eQ9++/YkTLOU CGGHFJwNJe2zV/0b61PDaKl01dS15SH2rY4GxlTONvQ5tAowbUL6YWgTK Q==; X-IronPort-AV: E=McAfee;i="6400,9594,10322"; a="288918165" X-IronPort-AV: E=Sophos;i="5.90,273,1643702400"; d="scan'208";a="288918165" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Apr 2022 10:07:13 -0700 X-IronPort-AV: E=Sophos;i="5.90,273,1643702400"; d="scan'208";a="576192246" Received: from ajacosta-mobl1.amr.corp.intel.com (HELO localhost) ([10.212.11.4]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Apr 2022 10:07:11 -0700 From: ira.weiny@intel.com To: Dave Hansen , "H. Peter Anvin" , Dan Williams Cc: Ira Weiny , Fenghua Yu , Rick Edgecombe , "Shankar, Ravi V" , linux-kernel@vger.kernel.org Subject: [PATCH V10 25/44] memremap_pages: Add Kconfig for DEVMAP_ACCESS_PROTECTION Date: Tue, 19 Apr 2022 10:06:30 -0700 Message-Id: <20220419170649.1022246-26-ira.weiny@intel.com> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220419170649.1022246-1-ira.weiny@intel.com> References: <20220419170649.1022246-1-ira.weiny@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE autolearn=ham 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: Ira Weiny The persistent memory (PMEM) driver uses the memremap_pages facility to provide 'struct page' metadata (vmemmap) for PMEM. Given that PMEM capacity may be orders of magnitude higher capacity than System RAM it presents a large vulnerability surface to stray writes. Unlike stray writes to System RAM, which may result in a crash or other undesirable behavior, stray writes to PMEM additionally are more likely to result in permanent data loss. Reboot is not a remediation for PMEM corruption like it is for System RAM. Given that PMEM access from the kernel is limited to a constrained set of locations (PMEM driver, Filesystem-DAX, and direct-I/O to a DAX page), it is amenable to supervisor pkey protection. Add a Kconfig option to configure additional devmap protections using PKS. Only PMEM which is advertised to the memory subsystem needs this protection. Therefore, the feature depends on NVDIMM_PFN. Signed-off-by: Ira Weiny --- Changes for V10 Rebased to latest Changes for V9 Change this to enable arch pks consumer for mutual exclusion with testing all pkeys From Dan Williams Default to no Clean up commit message Changes for V8 Split this out from [PATCH V7 13/18] memremap_pages: Add access protection via supervisor Protection Keys (PKS) --- mm/Kconfig | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/mm/Kconfig b/mm/Kconfig index 29c272974aa9..fe1752e6e76c 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -797,6 +797,24 @@ config ZONE_DEVICE If FS_DAX is enabled, then say Y. +config DEVMAP_ACCESS_PROTECTION + bool "Access protection for memremap_pages()" + depends on NVDIMM_PFN + depends on ARCH_HAS_SUPERVISOR_PKEYS + select ARCH_ENABLE_PKS_CONSUMER + default n + + help + Enable extra protections on device memory. This protects against + unintended access to devices such as a stray writes. This feature is + particularly useful to protect against corruption of persistent + memory. + + This depends on architecture support of supervisor PKeys and has no + overhead if the architecture does not support them. + + If you have persistent memory say 'Y'. + # # Helpers to mirror range of the CPU page tables of a process into device page # tables. -- 2.35.1