Linux kernel -stable discussions
 help / color / mirror / Atom feed
From: Jimmy Tran <jtoantran@google.com>
To: stable@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>,
	 Borislav Petkov <bp@alien8.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
	Christian Brauner <brauner@kernel.org>,
	 Arnd Bergmann <arnd@arndb.de>, Ingo Molnar <mingo@redhat.com>,
	 Dave Hansen <dave.hansen@linux.intel.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	 Will Deacon <will@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	 David Laight <david.laight@aculab.com>,
	Andrei Vagin <avagin@gmail.com>,
	 David Laight <David.Laight@aculab.com>,
	Jimmy Tran <jtoantran@google.com>
Subject: [PATCH v2 7/7] x86: use cmov for user address masking
Date: Wed,  6 Aug 2025 16:20:03 +0000	[thread overview]
Message-ID: <20250806162003.1134886-8-jtoantran@google.com> (raw)
In-Reply-To: <20250806162003.1134886-1-jtoantran@google.com>

From: Linus Torvalds <torvalds@linux-foundation.org>

commit 91309a70829d94c735c8bb1cc383e78c96127a16 upstream

This was a suggestion by David Laight, and while I was slightly worried
that some micro-architecture would predict cmov like a conditional
branch, there is little reason to actually believe any core would be
that broken.

Intel documents that their existing cores treat CMOVcc as a data
dependency that will constrain speculation in their "Speculative
Execution Side Channel Mitigations" whitepaper:

  "Other instructions such as CMOVcc, AND, ADC, SBB and SETcc can also
   be used to prevent bounds check bypass by constraining speculative
   execution on current family 6 processors (Intel® Core™, Intel® Atom™,
   Intel® Xeon® and Intel® Xeon Phi™ processors)"

and while that leaves the future uarch issues open, that's certainly
true of our traditional SBB usage too.

Any core that predicts CMOV will be unusable for various crypto
algorithms that need data-independent timing stability, so let's just
treat CMOV as the safe choice that simplifies the address masking by
avoiding an extra instruction and doesn't need a temporary register.

Cc: <stable@vger.kernel.org> # 6.12.x: 573f45a: x86: x86: fix off-by-one in access_ok()
Cc: <stable@vger.kernel.org> # 6.12.x: 86e6b15: x86: fix user address masking non-canonical speculation issue
Cc: <stable@vger.kernel.org> # 6.10.x: e60cc61: vfs: dcache: move hashlen_hash() from callers into d_hash()
Cc: <stable@vger.kernel.org> # 6.10.x: e782985: runtime constants: add default dummy infrastructure
Cc: <stable@vger.kernel.org> # 6.10.x: e3c92e8: runtime constants: add x86 architecture support
Suggested-by: David Laight <David.Laight@aculab.com>
Link: https://www.intel.com/content/dam/develop/external/us/en/documents/336996-speculative-execution-side-channel-mitigations.pdf
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Jimmy Tran <jtoantran@google.com>
---
 arch/x86/include/asm/uaccess_64.h | 13 ++++++-------
 arch/x86/lib/getuser.S            |  5 ++---
 2 files changed, 8 insertions(+), 10 deletions(-)

diff --git a/arch/x86/include/asm/uaccess_64.h b/arch/x86/include/asm/uaccess_64.h
index e68eded5ee490..123d36c89722f 100644
--- a/arch/x86/include/asm/uaccess_64.h
+++ b/arch/x86/include/asm/uaccess_64.h
@@ -66,14 +66,13 @@ static inline unsigned long __untagged_addr_remote(struct mm_struct *mm,
  */
 static inline void __user *mask_user_address(const void __user *ptr)
 {
-	unsigned long mask;
-
+	void __user *ret;
 	asm("cmp %1,%0\n\t"
-	    "sbb %0,%0"
-		 : "=r" (mask)
-		 : "r" (ptr),
-		 "0" (runtime_const_ptr(USER_PTR_MAX)));
-	return (__force void __user *)(mask | (__force unsigned long)ptr);
+	    "cmova %1,%0"
+		:"=r" (ret)
+		:"r" (runtime_const_ptr(USER_PTR_MAX)),
+		 "0" (ptr));
+	return ret;
 }
 
 /*
diff --git a/arch/x86/lib/getuser.S b/arch/x86/lib/getuser.S
index ffa3fff259578..0f7f58f20b068 100644
--- a/arch/x86/lib/getuser.S
+++ b/arch/x86/lib/getuser.S
@@ -44,9 +44,8 @@
   .pushsection runtime_ptr_USER_PTR_MAX,"a"
 	.long 1b - 8 - .
   .popsection
-	cmp %rax, %rdx
-	sbb %rdx, %rdx
-	or %rdx, %rax
+	cmp %rdx, %rax
+	cmova %rdx, %rax
 .else
 	cmp $TASK_SIZE_MAX-\size+1, %eax
 .if \size != 8
-- 
2.50.1.470.g6ba607880d-goog


  parent reply	other threads:[~2025-08-06 16:20 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-06 16:19 [PATCH 6.6 v2 0/7] x86: fix user address masking non-canonical Jimmy Tran
2025-08-06 16:19 ` [PATCH v2 1/7] vfs: dcache: move hashlen_hash() from callers into d_hash() Jimmy Tran
2025-08-06 16:19 ` [PATCH v2 2/7] runtime constants: add default dummy infrastructure Jimmy Tran
2025-08-12 13:00   ` Greg Kroah-Hartman
2025-08-06 16:19 ` [PATCH v2 3/7] runtime constants: add x86 architecture support Jimmy Tran
2025-08-06 21:01   ` David Laight
2025-08-06 16:20 ` [PATCH v2 4/7] arm64: add 'runtime constant' support Jimmy Tran
2025-08-06 16:20 ` [PATCH v2 5/7] x86: fix user address masking non-canonical speculation issue Jimmy Tran
2025-08-06 16:20 ` [PATCH v2 6/7] x86: fix off-by-one in access_ok() Jimmy Tran
2025-08-06 16:20 ` Jimmy Tran [this message]
2025-08-06 18:02 ` [PATCH 6.6 v2 0/7] x86: fix user address masking non-canonical Linus Torvalds
  -- strict thread matches above, loose matches on Subject: below --
2025-07-23 16:32 [PATCH v1 0/6] Backport "x86: fix off-by-one in access_ok()" to 6.6.y Jimmy Tran
2025-07-28 17:56 ` [PATCH v2 0/7] x86: fix user address masking non-canonical Jimmy Tran
2025-07-28 17:57   ` [PATCH v2 7/7] x86: use cmov for user address masking Jimmy Tran

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=20250806162003.1134886-8-jtoantran@google.com \
    --to=jtoantran@google.com \
    --cc=arnd@arndb.de \
    --cc=avagin@gmail.com \
    --cc=bp@alien8.de \
    --cc=brauner@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=david.laight@aculab.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=mingo@redhat.com \
    --cc=stable@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=will@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