BPF List
 help / color / mirror / Atom feed
From: Leo Yu-Chi Liang <ycliang@andestech.com>
To: <akpm@linux-foundation.org>, <urezki@gmail.com>,
	<hch@infradead.org>, <lstoakes@gmail.com>, <linux-mm@kvack.org>,
	<linux-kernel@vger.kernel.org>, <bpf@vger.kernel.org>,
	<rick.p.edgecombe@intel.com>
Cc: <patrick@andestech.com>, Leo Yu-Chi Liang <ycliang@andestech.com>
Subject: [RFC PATCH 1/1] mm/vmalloc: Modify permission reset procedure to avoid invalid access
Date: Tue, 11 Jun 2024 21:13:01 +0800	[thread overview]
Message-ID: <20240611131301.2988047-1-ycliang@andestech.com> (raw)

The previous reset procedure is
1. Set direct map attribute to invalid
2. Flush TLB
3. Reset direct map attribute to default

It is possible that kernel forks another process
on another core that access the invalid mappings after
sync_kernel_mappings.

We could reproduce this scenario by running LTP/bpf_prog
multiple times on RV32 kernel on QEMU.

Therefore, the following procedure is proposed
to avoid mappings being invalid.
1. Reset direct map attribute to default
2. Flush TLB

Signed-off-by: Leo Yu-Chi Liang <ycliang@andestech.com>
---
 mm/vmalloc.c | 9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 45e1506d58c3..58ef2fc51e43 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -3248,14 +3248,9 @@ static void vm_reset_perms(struct vm_struct *area)
 		}
 	}
 
-	/*
-	 * Set direct map to something invalid so that it won't be cached if
-	 * there are any accesses after the TLB flush, then flush the TLB and
-	 * reset the direct map permissions to the default.
-	 */
-	set_area_direct_map(area, set_direct_map_invalid_noflush);
-	_vm_unmap_aliases(start, end, flush_dmap);
+	/* Reset direct map permissions to default, then flush the TLB */
 	set_area_direct_map(area, set_direct_map_default_noflush);
+	_vm_unmap_aliases(start, end, flush_dmap);
 }
 
 static void delayed_vfree_work(struct work_struct *w)
-- 
2.34.1


             reply	other threads:[~2024-06-11 13:16 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-11 13:13 Leo Yu-Chi Liang [this message]
2024-06-11 14:21 ` [RFC PATCH 1/1] mm/vmalloc: Modify permission reset procedure to avoid invalid access Edgecombe, Rick P
2024-06-18 12:08   ` Leo Liang
2024-06-18 16:08     ` Edgecombe, Rick P

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=20240611131301.2988047-1-ycliang@andestech.com \
    --to=ycliang@andestech.com \
    --cc=akpm@linux-foundation.org \
    --cc=bpf@vger.kernel.org \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lstoakes@gmail.com \
    --cc=patrick@andestech.com \
    --cc=rick.p.edgecombe@intel.com \
    --cc=urezki@gmail.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