linux-arch.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Peter Anvin <hpa@zytor.com>, Ingo Molnar <mingo@kernel.org>,
	Borislav Petkov <bp@alien8.de>,
	Thomas Gleixner <tglx@linutronix.de>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	the arch/x86 maintainers <x86@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-arch <linux-arch@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: [PATCH 7/7] arm64: access_ok() optimization
Date: Mon, 10 Jun 2024 13:48:21 -0700	[thread overview]
Message-ID: <20240610204821.230388-8-torvalds@linux-foundation.org> (raw)
In-Reply-To: <20240610204821.230388-1-torvalds@linux-foundation.org>

The TBI setup on arm64 is very strange: HW is set up to always do TBI,
but the kernel enforcement for system calls is purely a software
contract, and user space is supposed to mask off the top bits before the
system call.

Except all the actual brk/mmap/etc() system calls then mask it in kernel
space anyway, and accept any TBI address.

This basically unifies things and makes access_ok() also ignore it.

This is an ABI change, but the current situation is very odd, and this
change avoids the current mess and makes the kernel more permissive, and
as such is unlikely to break anything.

The way forward - for some possible future situation when people want to
use more bits - is probably to introduce a new "I actually want the full
64-bit address space" prctl.  But we should make sure that the software
and hardware rules actually match at that point.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
 arch/arm64/include/asm/uaccess.h | 23 ++++++++++-------------
 1 file changed, 10 insertions(+), 13 deletions(-)

diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
index 4ab3938290ab..a435eff4ee93 100644
--- a/arch/arm64/include/asm/uaccess.h
+++ b/arch/arm64/include/asm/uaccess.h
@@ -30,23 +30,20 @@ static inline int __access_ok(const void __user *ptr, unsigned long size);
 
 /*
  * Test whether a block of memory is a valid user space address.
- * Returns 1 if the range is valid, 0 otherwise.
  *
- * This is equivalent to the following test:
- * (u65)addr + (u65)size <= (u65)TASK_SIZE_MAX
+ * We only care that the address cannot reach the kernel mapping, and
+ * that an invalid address will fault.
  */
-static inline int access_ok(const void __user *addr, unsigned long size)
+static inline int access_ok(const void __user *p, unsigned long size)
 {
-	/*
-	 * Asynchronous I/O running in a kernel thread does not have the
-	 * TIF_TAGGED_ADDR flag of the process owning the mm, so always untag
-	 * the user address before checking.
-	 */
-	if (IS_ENABLED(CONFIG_ARM64_TAGGED_ADDR_ABI) &&
-	    (current->flags & PF_KTHREAD || test_thread_flag(TIF_TAGGED_ADDR)))
-		addr = untagged_addr(addr);
+	unsigned long addr = (unsigned long)p;
 
-	return likely(__access_ok(addr, size));
+	/* Only bit 55 of the address matters */
+	addr |= addr+size;
+	addr = (addr >> 55) & 1;
+	size >>= 55;
+
+	return !(addr | size);
 }
 #define access_ok access_ok
 
-- 
2.45.1.209.gc6f12300df


  parent reply	other threads:[~2024-06-10 20:48 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-10 20:48 [PATCH 0/7] arm64 / x86-64: low-level code generation issues Linus Torvalds
2024-06-10 20:48 ` [PATCH 1/7] vfs: dcache: move hashlen_hash() from callers into d_hash() Linus Torvalds
2024-06-10 20:48 ` [PATCH 2/7] add default dummy 'runtime constant' infrastructure Linus Torvalds
2024-06-12 10:04   ` Borislav Petkov
2024-06-10 20:48 ` [PATCH 3/7] x86: add 'runtime constant' support Linus Torvalds
2024-06-10 20:48 ` [PATCH 4/7] arm64: " Linus Torvalds
2024-06-11 14:29   ` Mark Rutland
2024-06-11 16:56     ` Linus Torvalds
2024-06-11 17:20       ` [PATCH 4/7 v2] " Linus Torvalds
2024-06-12 18:42         ` Mark Rutland
2024-06-11 17:48       ` [PATCH 4/7] " Mark Rutland
2024-06-11 17:59         ` Linus Torvalds
2024-06-11 18:59           ` Linus Torvalds
2024-06-11 20:22             ` Mark Rutland
2024-06-11 21:08               ` Linus Torvalds
2024-06-10 20:48 ` [PATCH 5/7] arm64: start using 'asm goto' for get_user() when available Linus Torvalds
2024-06-10 20:48 ` [PATCH 6/7] arm64: start using 'asm goto' for put_user() " Linus Torvalds
2024-06-11 21:55   ` Nathan Chancellor
2024-06-11 23:29     ` Linus Torvalds
2024-06-11 23:40       ` [PATCH 6/7 v2] " Linus Torvalds
2024-06-10 20:48 ` Linus Torvalds [this message]
2024-06-12 18:41 ` [PATCH 0/7] arm64 / x86-64: low-level code generation issues Mark Rutland
2024-06-12 20:02   ` Linus Torvalds
2024-06-12 22:25     ` Linus Torvalds

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=20240610204821.230388-8-torvalds@linux-foundation.org \
    --to=torvalds@linux-foundation.org \
    --cc=bp@alien8.de \
    --cc=catalin.marinas@arm.com \
    --cc=hpa@zytor.com \
    --cc=jpoimboe@kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=mingo@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=will@kernel.org \
    --cc=x86@kernel.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: 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;
as well as URLs for NNTP newsgroup(s).