All of lore.kernel.org
 help / color / mirror / Atom feed
From: ira.weiny@intel.com
To: Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Dan Williams <dan.j.williams@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>,
	Rick Edgecombe <rick.p.edgecombe@intel.com>,
	"Shankar, Ravi V" <ravi.v.shankar@intel.com>,
	linux-kernel@vger.kernel.org
Subject: [PATCH V10 31/44] memremap_pages: Define pgmap_set_{readwrite|noaccess}() calls
Date: Tue, 19 Apr 2022 10:06:36 -0700	[thread overview]
Message-ID: <20220419170649.1022246-32-ira.weiny@intel.com> (raw)
In-Reply-To: <20220419170649.1022246-1-ira.weiny@intel.com>

From: Ira Weiny <ira.weiny@intel.com>

A thread that wants to access memory protected by PGMAP protections must
first enable access, and then disable access when it is done.

Introduce pgmap_set_{readwrite|noaccess}() for this purpose.  The two
calls are destined to be used by the kmap API and take a struct page for
convenience.  They determine if the page is protected and, if so,
perform the requested operation.

Toggling between Read/Write and No Access was chosen as it fits well
with the accessibility of a kmap'ed page.  Discussions did occur
regarding making a finer grained mapping for Read Only but that is
something which can be added at a later date.

In addition, two lower level functions are exported.  They take the
dev_pagemap object directly for internal consumers who have knowledge of
the of the dev_pagemap.

All changes in the protections must be through the above calls.  They
abstract the protection implementation (currently the PKS API) from
upper layer consumers.

The calls are made nestable by the use of a per task reference count.
This ensures that the first call to re-enable protection does not
'break' the last access of the device memory.  Expansion of the task
struct is unavoidable due to the desire to maintain kmap_local_page() as
non-atomic and migratable.  The only other idea to track a reference
count was in a per-cpu variable.  However, doing so would make
kmap_local_page() equivalent to kmap_atomic() which is undesirable.

Access to device memory during exceptions (#PF) is expected only from
user faults.  Therefore there is no need to maintain the reference count
during exceptions.

NOTE: It is not anticipated that any code path will directly nest these
calls.  For this reason multiple reviewers, including Dan and Thomas,
asked why this reference counting was needed at this level rather than
in a higher level call such as kmap_local_page().  The reason is that
pgmap_set_readwrite() can nest with kmap_{atomic,local_page}().
Therefore this reference counting is pushed to the lower level to ensure
that any combination of calls is nestable.

Signed-off-by: Ira Weiny <ira.weiny@intel.com>

---
Changes for V10
	Move code from mm.h to memremap.h
		Upstream separated memremap.h functionality from mm.h
		dc90f0846df4 ("mm: don't include <linux/memremap.h> in <linux/mm.h>")

Changes for V9
	From Dan Williams
		Update the commit message with details on why the thread
			struct needs to be expanded.
	Following on Dave Hansens suggestion for pks_mk
		s/pgmap_mk_*/pgmap_set_*/

Changes for V8
	Split these functions into their own patch.
		This helps to clarify the commit message and usage.
---
 include/linux/memremap.h | 35 +++++++++++++++++++++++++++++++++++
 include/linux/sched.h    |  7 +++++++
 init/init_task.c         |  3 +++
 mm/memremap.c            | 14 ++++++++++++++
 4 files changed, 59 insertions(+)

diff --git a/include/linux/memremap.h b/include/linux/memremap.h
index 6325f00096ec..1012c6c4c664 100644
--- a/include/linux/memremap.h
+++ b/include/linux/memremap.h
@@ -240,8 +240,43 @@ static inline bool devmap_protected(struct page *page)
 	return false;
 }
 
+void __pgmap_set_readwrite(struct dev_pagemap *pgmap);
+void __pgmap_set_noaccess(struct dev_pagemap *pgmap);
+
+static inline bool pgmap_check_pgmap_prot(struct page *page)
+{
+	if (!devmap_protected(page))
+		return false;
+
+	/*
+	 * There is no known use case to change permissions in an irq for pgmap
+	 * pages
+	 */
+	lockdep_assert_in_irq();
+	return true;
+}
+
+static inline void pgmap_set_readwrite(struct page *page)
+{
+	if (!pgmap_check_pgmap_prot(page))
+		return;
+	__pgmap_set_readwrite(page->pgmap);
+}
+
+static inline void pgmap_set_noaccess(struct page *page)
+{
+	if (!pgmap_check_pgmap_prot(page))
+		return;
+	__pgmap_set_noaccess(page->pgmap);
+}
+
 #else
 
+static inline void __pgmap_set_readwrite(struct dev_pagemap *pgmap) { }
+static inline void __pgmap_set_noaccess(struct dev_pagemap *pgmap) { }
+static inline void pgmap_set_readwrite(struct page *page) { }
+static inline void pgmap_set_noaccess(struct page *page) { }
+
 static inline bool pgmap_protection_available(void)
 {
 	return false;
diff --git a/include/linux/sched.h b/include/linux/sched.h
index d5e3c00b74e1..7da0d2a0ac74 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1498,6 +1498,13 @@ struct task_struct {
 	struct callback_head		l1d_flush_kill;
 #endif
 
+#ifdef CONFIG_DEVMAP_ACCESS_PROTECTION
+	/*
+	 * NOTE: pgmap_prot_count is modified within a single thread of
+	 * execution.  So it does not need to be atomic_t.
+	 */
+	u32                             pgmap_prot_count;
+#endif
 	/*
 	 * New fields for task_struct should be added above here, so that
 	 * they are included in the randomized portion of task_struct.
diff --git a/init/init_task.c b/init/init_task.c
index 73cc8f03511a..948b32cf8139 100644
--- a/init/init_task.c
+++ b/init/init_task.c
@@ -209,6 +209,9 @@ struct task_struct init_task
 #ifdef CONFIG_SECCOMP_FILTER
 	.seccomp	= { .filter_count = ATOMIC_INIT(0) },
 #endif
+#ifdef CONFIG_DEVMAP_ACCESS_PROTECTION
+	.pgmap_prot_count = 0,
+#endif
 };
 EXPORT_SYMBOL(init_task);
 
diff --git a/mm/memremap.c b/mm/memremap.c
index 215ab9c51917..491bb49255ae 100644
--- a/mm/memremap.c
+++ b/mm/memremap.c
@@ -94,6 +94,20 @@ static void devmap_protection_disable(void)
 	static_branch_dec(&dev_pgmap_protection_static_key);
 }
 
+void __pgmap_set_readwrite(struct dev_pagemap *pgmap)
+{
+	if (!current->pgmap_prot_count++)
+		pks_set_readwrite(PKS_KEY_PGMAP_PROTECTION);
+}
+EXPORT_SYMBOL_GPL(__pgmap_set_readwrite);
+
+void __pgmap_set_noaccess(struct dev_pagemap *pgmap)
+{
+	if (!--current->pgmap_prot_count)
+		pks_set_noaccess(PKS_KEY_PGMAP_PROTECTION);
+}
+EXPORT_SYMBOL_GPL(__pgmap_set_noaccess);
+
 #else /* !CONFIG_DEVMAP_ACCESS_PROTECTION */
 
 static void devmap_protection_enable(void) { }
-- 
2.35.1


  parent reply	other threads:[~2022-04-19 17:08 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-19 17:06 [PATCH V10 00/44] PKS/PMEM: Add Stray Write Protection ira.weiny
2022-04-19 17:06 ` [PATCH V10 01/44] Documentation/protection-keys: Clean up documentation for User Space pkeys ira.weiny
2022-06-07 23:09   ` [tip: x86/mm] " tip-bot2 for Ira Weiny
2022-04-19 17:06 ` [PATCH V10 02/44] x86/pkeys: Clarify PKRU_AD_KEY macro ira.weiny
2022-06-07 23:09   ` [tip: x86/mm] " tip-bot2 for Ira Weiny
2022-04-19 17:06 ` [PATCH V10 03/44] x86/pkeys: Make PKRU macros generic ira.weiny
2022-04-19 17:06 ` [PATCH V10 04/44] x86/fpu: Refactor arch_set_user_pkey_access() ira.weiny
2022-04-19 17:06 ` [PATCH V10 05/44] mm/pkeys: Add Kconfig options for PKS ira.weiny
2022-04-19 17:06 ` [PATCH V10 06/44] x86/pkeys: Add PKS CPU feature bit ira.weiny
2022-04-19 17:06 ` [PATCH V10 07/44] x86/fault: Adjust WARN_ON for pkey fault ira.weiny
2022-04-19 17:06 ` [PATCH V10 08/44] Documentation/pkeys: Add initial PKS documentation ira.weiny
2022-05-09 22:03   ` Kees Cook
2022-05-10 17:18     ` Ira Weiny
2022-05-10 20:17       ` Kees Cook
2022-04-19 17:06 ` [PATCH V10 09/44] mm/pkeys: Provide for PKS key allocation ira.weiny
2022-04-19 17:06 ` [PATCH V10 10/44] x86/pkeys: Enable PKS on cpus which support it ira.weiny
2022-04-19 17:06 ` [PATCH V10 11/44] mm/pkeys: Define PKS page table macros ira.weiny
2022-04-19 17:06 ` [PATCH V10 12/44] x86/pkeys: Introduce pks_write_pkrs() ira.weiny
2022-04-19 17:06 ` [PATCH V10 13/44] x86/pkeys: Preserve the PKS MSR on context switch ira.weiny
2022-04-19 17:06 ` [PATCH V10 14/44] mm/pkeys: Introduce pks_set_readwrite() ira.weiny
2022-05-09 21:38   ` Kees Cook
2022-05-10 21:33     ` Ira Weiny
2022-05-10 22:08       ` Kees Cook
2022-05-10 22:26         ` Edgecombe, Rick P
2022-05-11  3:15           ` Kees Cook
2022-05-11 17:59             ` Ira Weiny
2022-04-19 17:06 ` [PATCH V10 15/44] mm/pkeys: Introduce pks_set_noaccess() ira.weiny
2022-04-19 17:06 ` [PATCH V10 16/44] mm/pkeys: Introduce PKS fault callbacks ira.weiny
2022-04-19 17:06 ` [PATCH V10 17/44] x86/entry: Add auxiliary pt_regs space ira.weiny
2022-04-19 17:06 ` [PATCH V10 18/44] entry: Pass pt_regs to irqentry_exit_cond_resched() ira.weiny
2022-04-19 17:06 ` [PATCH V10 19/44] entry: Add calls for save/restore auxiliary pt_regs ira.weiny
2022-04-19 17:06 ` [PATCH V10 20/44] x86/entry: Define arch_{save|restore}_auxiliary_pt_regs() ira.weiny
2022-04-19 17:06 ` [PATCH V10 21/44] x86/pkeys: Preserve PKRS MSR across exceptions ira.weiny
2022-04-19 17:06 ` [PATCH V10 22/44] x86/fault: Print PKS MSR on fault ira.weiny
2022-04-19 17:06 ` [PATCH V10 23/44] mm/pkeys: Introduce pks_update_exception() ira.weiny
2022-04-19 17:06 ` [PATCH V10 24/44] mm/pkeys: Add pks_available() ira.weiny
2022-04-19 17:06 ` [PATCH V10 25/44] memremap_pages: Add Kconfig for DEVMAP_ACCESS_PROTECTION ira.weiny
2022-04-19 17:06 ` [PATCH V10 26/44] memremap_pages: Introduce pgmap_protection_available() ira.weiny
2022-04-19 17:06 ` [PATCH V10 27/44] memremap_pages: Introduce a PGMAP_PROTECTION flag ira.weiny
2022-04-19 17:06 ` [PATCH V10 28/44] memremap_pages: Introduce devmap_protected() ira.weiny
2022-04-19 17:06 ` [PATCH V10 29/44] memremap_pages: Reserve a PKS pkey for eventual use by PMEM ira.weiny
2022-04-19 17:06 ` [PATCH V10 30/44] memremap_pages: Set PKS pkey in PTEs if requested ira.weiny
2022-04-19 17:06 ` ira.weiny [this message]
2022-04-19 17:06 ` [PATCH V10 32/44] memremap_pages: Add memremap.pks_fault_mode ira.weiny
2022-04-19 17:06 ` [PATCH V10 33/44] kmap: Make kmap work for devmap protected pages ira.weiny
2022-04-28 15:50   ` Christoph Hellwig
2022-05-12  1:25     ` Ira Weiny
2022-05-17 22:46       ` Ira Weiny
2022-05-18  7:33         ` Christoph Hellwig
2022-05-19 20:29           ` Ira Weiny
2022-04-19 17:06 ` [PATCH V10 34/44] dax: Stray access protection for dax_direct_access() ira.weiny
2022-04-19 17:06 ` [PATCH V10 35/44] nvdimm/pmem: Enable stray access protection ira.weiny
2022-04-19 17:06 ` [PATCH V10 36/44] devdax: " ira.weiny
2022-04-19 17:06 ` [PATCH V10 37/44] mm/pkeys: PKS testing, add initial test code ira.weiny
2022-04-19 17:06 ` [PATCH V10 38/44] x86/selftests: Add test_pks ira.weiny
2022-04-19 17:06 ` [PATCH V10 39/44] mm/pkeys: PKS testing, add a fault call back ira.weiny
2022-04-19 17:06 ` [PATCH V10 40/44] mm/pkeys: PKS testing, add pks_set_*() tests ira.weiny
2022-04-19 17:06 ` [PATCH V10 41/44] mm/pkeys: PKS testing, test context switching ira.weiny
2022-04-19 17:06 ` [PATCH V10 42/44] mm/pkeys: PKS testing, Add exception test ira.weiny
2022-04-19 17:06 ` [PATCH V10 43/44] mm/pkeys: PKS testing, test pks_update_exception() ira.weiny
2022-04-19 17:06 ` [PATCH V10 44/44] mm/pkeys: PKS testing, add test for all keys ira.weiny

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220419170649.1022246-32-ira.weiny@intel.com \
    --to=ira.weiny@intel.com \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=fenghua.yu@intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ravi.v.shankar@intel.com \
    --cc=rick.p.edgecombe@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.