From: Will Deacon <will@kernel.org> To: linux-kernel@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org, kernel-team@android.com, Will Deacon <will@kernel.org>, Catalin Marinas <catalin.marinas@arm.com>, Linus Torvalds <torvalds@linux-foundation.org> Subject: [PATCH] mm/mremap: Add comment explaining the untagging behaviour of mremap() Date: Wed, 25 Mar 2020 11:13:46 +0000 [thread overview] Message-ID: <20200325111347.32553-1-will@kernel.org> (raw) Commit dcde237319e6 ("mm: Avoid creating virtual address aliases in brk()/mmap()/mremap()") changed mremap() so that only the 'old' address is untagged, leaving the 'new' address in the form it was passed from userspace. This prevents the unexpected creation of aliasing virtual mappings in userspace, but looks a bit odd when you read the code. Add a comment justifying the untagging behaviour in mremap(). Cc: Catalin Marinas <catalin.marinas@arm.com> Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Will Deacon <will@kernel.org> --- mm/mremap.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/mm/mremap.c b/mm/mremap.c index af363063ea23..d28f08a36b96 100644 --- a/mm/mremap.c +++ b/mm/mremap.c @@ -606,6 +606,16 @@ SYSCALL_DEFINE5(mremap, unsigned long, addr, unsigned long, old_len, LIST_HEAD(uf_unmap_early); LIST_HEAD(uf_unmap); + /* + * There is a deliberate asymmetry here: we strip the pointer tag + * from the old address but leave the new address alone. This is + * for consistency with mmap(), where we prevent the creation of + * aliasing mappings in userspace by leaving the tag bits of the + * mapping address intact. A non-zero tag will cause the subsequent + * range checks to reject the address as invalid. + * + * See Documentation/arm64/tagged-address-abi.rst for more information. + */ addr = untagged_addr(addr); if (flags & ~(MREMAP_FIXED | MREMAP_MAYMOVE)) -- 2.25.1.696.g5e7596f4ac-goog
WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will@kernel.org> To: linux-kernel@vger.kernel.org Cc: Will Deacon <will@kernel.org>, Linus Torvalds <torvalds@linux-foundation.org>, kernel-team@android.com, linux-arm-kernel@lists.infradead.org, Catalin Marinas <catalin.marinas@arm.com> Subject: [PATCH] mm/mremap: Add comment explaining the untagging behaviour of mremap() Date: Wed, 25 Mar 2020 11:13:46 +0000 [thread overview] Message-ID: <20200325111347.32553-1-will@kernel.org> (raw) Commit dcde237319e6 ("mm: Avoid creating virtual address aliases in brk()/mmap()/mremap()") changed mremap() so that only the 'old' address is untagged, leaving the 'new' address in the form it was passed from userspace. This prevents the unexpected creation of aliasing virtual mappings in userspace, but looks a bit odd when you read the code. Add a comment justifying the untagging behaviour in mremap(). Cc: Catalin Marinas <catalin.marinas@arm.com> Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Will Deacon <will@kernel.org> --- mm/mremap.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/mm/mremap.c b/mm/mremap.c index af363063ea23..d28f08a36b96 100644 --- a/mm/mremap.c +++ b/mm/mremap.c @@ -606,6 +606,16 @@ SYSCALL_DEFINE5(mremap, unsigned long, addr, unsigned long, old_len, LIST_HEAD(uf_unmap_early); LIST_HEAD(uf_unmap); + /* + * There is a deliberate asymmetry here: we strip the pointer tag + * from the old address but leave the new address alone. This is + * for consistency with mmap(), where we prevent the creation of + * aliasing mappings in userspace by leaving the tag bits of the + * mapping address intact. A non-zero tag will cause the subsequent + * range checks to reject the address as invalid. + * + * See Documentation/arm64/tagged-address-abi.rst for more information. + */ addr = untagged_addr(addr); if (flags & ~(MREMAP_FIXED | MREMAP_MAYMOVE)) -- 2.25.1.696.g5e7596f4ac-goog _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next reply other threads:[~2020-03-25 11:13 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-03-25 11:13 Will Deacon [this message] 2020-03-25 11:13 ` [PATCH] mm/mremap: Add comment explaining the untagging behaviour of mremap() Will Deacon 2020-03-25 11:23 ` Catalin Marinas 2020-03-25 11:23 ` Catalin Marinas 2020-03-25 17:33 ` Linus Torvalds 2020-03-25 17:33 ` Linus Torvalds 2020-03-26 11:33 ` Catalin Marinas 2020-03-26 11:33 ` 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=20200325111347.32553-1-will@kernel.org \ --to=will@kernel.org \ --cc=catalin.marinas@arm.com \ --cc=kernel-team@android.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=torvalds@linux-foundation.org \ /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: linkBe 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.