linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Florent Revest <revest@chromium.org>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	akpm@linux-foundation.org, anshuman.khandual@arm.com,
	joey.gouly@arm.com, mhocko@suse.com, keescook@chromium.org,
	david@redhat.com, peterx@redhat.com, izbyshev@ispras.ru,
	nd@arm.com, broonie@kernel.org, szabolcs.nagy@arm.com
Subject: Re: [PATCH 3/4] mm: Add a NO_INHERIT flag to the PR_SET_MDWE prctl
Date: Fri, 5 May 2023 19:34:21 +0100	[thread overview]
Message-ID: <ZFVMLQHObyP4Na+j@arm.com> (raw)
In-Reply-To: <20230504170942.822147-4-revest@chromium.org>

On Thu, May 04, 2023 at 07:09:41PM +0200, Florent Revest wrote:
> This extends the current PR_SET_MDWE prctl arg with a bit to indicate
> that the process doesn't want MDWE protection to propagate to children.
> 
> To implement this no-inherit mode, the tag in current->mm->flags must be
> absent from MMF_INIT_MASK. This means that the encoding for "MDWE but
> without inherit" is different in the prctl than in the mm flags. This
> leads to a bit of bit-mangling in the prctl implementation.

That bit mangling is not that bad but it complicates the code a bit,
especially if we'll add new bits in the future. We also need to check
both the original and the no-inherit bits for each feature.

Another question is whether we want to support more fine-grained
inheriting or just a big knob that disables inheriting for all the
(future) MDWE flags.

I think a somewhat simpler way would be to clear the flags on fork(),
either based on a big MMF_HAS_MDWE_NO_INHERIT knob or individual ones.
Something like below (completely untested):

diff --git a/include/linux/sched/coredump.h b/include/linux/sched/coredump.h
index 0ee96ea7a0e9..ca83a0c8d19c 100644
--- a/include/linux/sched/coredump.h
+++ b/include/linux/sched/coredump.h
@@ -91,4 +91,12 @@ static inline int get_dumpable(struct mm_struct *mm)
 				 MMF_DISABLE_THP_MASK | MMF_HAS_MDWE_MASK)

 #define MMF_VM_MERGE_ANY	29
+
+#define MMF_INIT_FLAGS(flags)	({				\
+	unsigned long new_flags = flags;			\
+	if (new_flags & (1UL << MMF_HAS_MDWE_NO_INHERIT))	\
+		new_flags &= ~(1UL << MMF_HAS_MDWE_MASK);	\
+	new_flags & MMF_INIT_MASK;				\
+})
+
 #endif /* _LINUX_SCHED_COREDUMP_H */
diff --git a/kernel/fork.c b/kernel/fork.c
index ed4e01daccaa..53f0b68a5451 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1288,7 +1288,7 @@ static struct mm_struct *mm_init(struct mm_struct *mm, struct task_struct *p,
 	hugetlb_count_init(mm);

 	if (current->mm) {
-		mm->flags = current->mm->flags & MMF_INIT_MASK;
+		mm->flags = MMF_INIT_FLAGS(current->mm->flags);
 		mm->def_flags = current->mm->def_flags & VM_INIT_DEF_MASK;
 	} else {
 		mm->flags = default_dump_filter;

The checks in MMF_INIT_FLAGS() can grow in time if we add more bits in
there but we still only keep a single flag that determines whether the
feature is enabled (maybe that's more like bikeshedding at this moment
when we have a single bit).


(fun remark: I see you cc'ed nd@arm.com'; that's not a real person, it's
what our IT folk asked us to add on cc so that the Exchange server
doesn't append the legal disclaimer; most lists are covered already
without such cc but I guess people feel safer to add it, just in case)

-- 
Catalin


  reply	other threads:[~2023-05-05 18:34 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-04 17:09 [PATCH 0/4] MDWE without inheritance Florent Revest
2023-05-04 17:09 ` [PATCH 1/4] kselftest: vm: Fix tabs/spaces inconsistency in the mdwe test Florent Revest
2023-05-04 17:09 ` [PATCH 2/4] kselftest: vm: Fix mdwe's mmap_FIXED test case Florent Revest
2023-05-04 17:13   ` Florent Revest
2023-05-04 17:09 ` [PATCH 3/4] mm: Add a NO_INHERIT flag to the PR_SET_MDWE prctl Florent Revest
2023-05-05 18:34   ` Catalin Marinas [this message]
2023-05-08 12:11     ` Florent Revest
2023-05-04 17:09 ` [PATCH 4/4] kselftest: vm: Add tests for no-inherit memory-deny-write-execute Florent Revest
2023-05-04 20:29   ` Alexey Izbyshev
2023-05-05 16:42     ` Florent Revest
2023-05-05 21:26       ` Alexey Izbyshev
2023-05-08 12:12         ` Florent Revest
2023-05-04 20:06 ` [PATCH 0/4] MDWE without inheritance Peter Xu
2023-05-05 16:42   ` Florent Revest
2023-05-08  1:29     ` Peter Xu
2023-05-08 12:12       ` Florent Revest
2023-05-08 14:10         ` Catalin Marinas
2023-05-08 17:21           ` Topi Miettinen
2023-05-09 10:04             ` Catalin Marinas

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=ZFVMLQHObyP4Na+j@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=anshuman.khandual@arm.com \
    --cc=broonie@kernel.org \
    --cc=david@redhat.com \
    --cc=izbyshev@ispras.ru \
    --cc=joey.gouly@arm.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=nd@arm.com \
    --cc=peterx@redhat.com \
    --cc=revest@chromium.org \
    --cc=szabolcs.nagy@arm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox