From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9220926D4CD for ; Mon, 29 Dec 2025 12:32:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767011538; cv=none; b=U47kpr9uCy8RqP6rlHIw8jyRo5AV6OFqMihTGUk8SA/TkYoqwYYk/b8wp5c4nhCT+ayFk0Ph2hxN2LvMg0XDnL9N1fqFLzHAPzasg21E5FGl+Q6oEMxwQ42VnA9isolGPCEuI7ctEAdZHzSW4G+11gtXrAXqSQOx4UygNxbXYRY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767011538; c=relaxed/simple; bh=F/zh6uCJBmATk75FVXr1YcctuzE3U0VvOJoh8dNDL2I=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=fHDABM/lQUhTJsml/joBRplva8dBs1Jn7iLLBMzDcLoVO1n3Jb20pN7E1nKkSGeL2ui3wc9kUnmS1D5TWi6/ddXUlEY6/LbJ9av96XNO/Br4kO3jjlkbFxSl3relfKHeNbqzFMo7CNE5p2RiST49UIg5FGZ61VTCFEG/HKCcadE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=EvSLzuTk; arc=none smtp.client-ip=209.85.128.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="EvSLzuTk" Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-477632b0621so56185285e9.2 for ; Mon, 29 Dec 2025 04:32:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767011535; x=1767616335; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=h2V9Ak1hhV3PFxTTSxFSosEA2ZLO7sEq/1ixLGM2KGU=; b=EvSLzuTk4aFAGq6JP7cveX1UnDeHZcqC3EkOhJ9bjw2b+9Lssp87yuyPgOqAIsRM7l xenu63UsafwkP7dWfmyXev793Q5IemvgSV0jAzJe1UTzHYCl8+HbhugynmHzRWtAOcZ2 9wwZalBjQ5C2/HLQHj+U/9huxwzYhP+v6/BU33Wi1L/5Pv8Va0fQHAMi9sLGIAhXe3wP iFiKLuVG/Ym1ODz6WndwrDeIrHSyG6eFarY87h0oR9st4HuO4Y3b5hd8AYc/UoK0p8dE IHn8FBzPe07k5yKuboE4XOsE2ZPDX6BYKhG1aFkACpCfLONdsYYYU80iJbQf22Z/dskN skTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767011535; x=1767616335; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=h2V9Ak1hhV3PFxTTSxFSosEA2ZLO7sEq/1ixLGM2KGU=; b=qC32PZgIVTlYIlo1pUksnMKKzGdHRTu18y7Sr9F360/UKew9u/zfYkRDFaQPHq1FAi tU8EYxZ3vtF1VoCMBbV98R9Mn9pucYXc4dLTJoa0lSWkG3903wgTuwts7aYFP3RSeglC iEJzIWHefwgeHn4uisUgtPMvUjZbljJL7Nz4m9qMmC8WJXD/A3GUJ/v7XzXlHHvcpc3Z 57QTM7cMe8FNOvGnJeZd1ReIQ/rOFRGivGGyNjKw2vaavgvTS7JMwkEG/Lfq+QINvxGu oZvVmXxwFHi4ZH5YiHi26P6KwZD5yoi+5QlqGQRC7CM5UD48DXTfgX/dJM7yDIilYokX ooeA== X-Forwarded-Encrypted: i=1; AJvYcCXGGZGYsDNyUbtWohPkqOljjOrPOv02kxoTZJcmnoMz5PUuhZuzIJ5B4N2aUGJQFmjfC5j+1d84/huHfDg=@vger.kernel.org X-Gm-Message-State: AOJu0YwxTGE2hkGv/IAhUsuzisNsz1PTE3vBkhb0J7WnOKjx6H692hbB G/NRH2khAsfrFshS7tQV12NBsVtxbWa5SJYudApXLsjFqiW9ZCYBQZrd X-Gm-Gg: AY/fxX7S1dG7A/eIiApeMMv8mSGzXiRpnPM9LhuETJZfJiTNGPOgtHABz7vFN95/0n5 a1Vyp7u8Hiju136sBm1ADtnZYdzE57z67SH/XT/e1Tmo3turnkyPCGaKlblwSaUZ/dIedRPV6bV f3Dr12y11wAuUK/iWxQvq0j3wDdtQBwUY55SQcxVy9o+tTraGj3B8mU6NdbRH3dJkPz8GFcxHZu 6xlyE4Dt4j6qqHqVMT/3V3dLMhL9hH4fc43i0eMAgJEMwbwHw558uedYT3dJwXjVrgAWyt0YIzw NeRDr+ZY9o7L4qECL1zxattjlYrQlu3iZ2oUsFdu11an+Tnb/ScwonA/MvKp0hooJCivUP5YUVZ n0Syh7oSLud9I9AcG2PvQbFr2J1KFUgj2sxIPPSwb4YrDj/XHtnyO4wjgmhNbSow+c2AfnVW3F/ 31N9RFniD4ttjqfn3e6mjuQRXe11oFDSw8o+3E7ErqcOD+25RWsuzP X-Google-Smtp-Source: AGHT+IG4R0XM6pGY+rb+2/l7j74aLN1kVTk1EU43NCr+8FaP/KTxj4Yb63lWebxPABA2dOPJSd8OUw== X-Received: by 2002:a05:600c:1389:b0:47d:403e:4eaf with SMTP id 5b1f17b1804b1-47d403e4fd0mr167579975e9.10.1767011534639; Mon, 29 Dec 2025 04:32:14 -0800 (PST) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47be3aac6d9sm245141465e9.4.2025.12.29.04.32.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Dec 2025 04:32:14 -0800 (PST) Date: Mon, 29 Dec 2025 12:32:12 +0000 From: David Laight To: Deepak Gupta Cc: Lukas Gerlach , linux-riscv@lists.infradead.org, palmer@dabbelt.com, pjw@kernel.org, aou@eecs.berkeley.edu, alex@ghiti.fr, linux-kernel@vger.kernel.org, daniel.weber@cispa.de, michael.schwarz@cispa.de, marton.bognar@kuleuven.be, jo.vanbulck@kuleuven.be Subject: Re: [PATCH 1/2] riscv: Use pointer masking to limit uaccess speculation Message-ID: <20251229123212.25ef3c4b@pumpkin> In-Reply-To: <20251228223430.43f14d51@pumpkin> References: <20251218191332.35849-1-lukas.gerlach@cispa.de> <20251218191332.35849-2-lukas.gerlach@cispa.de> <20251227212859.3a83d65e@pumpkin> <20251228223430.43f14d51@pumpkin> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Sun, 28 Dec 2025 22:34:30 +0000 David Laight wrote: > On Sat, 27 Dec 2025 17:59:38 -0800 > Deepak Gupta wrote: > > > On Sat, Dec 27, 2025 at 09:28:59PM +0000, David Laight wrote: > > >On Fri, 19 Dec 2025 16:44:11 -0800 > > >Deepak Gupta wrote: > > > > > >> On Thu, Dec 18, 2025 at 08:13:31PM +0100, Lukas Gerlach wrote: > > >> >Similarly to x86 and arm64, mitigate speculation past an access_ok() > > >> >check by masking the pointer before use. > > >> > > > >> >On RISC-V, user addresses have the MSB clear while kernel addresses > > >> >have the MSB set. The uaccess_mask_ptr() function clears the MSB, > > >> >ensuring any kernel pointer becomes invalid and will fault, while > > >> >valid user pointers remain unchanged. This prevents speculative > > >> >access to kernel memory via user copy functions. > > >> > > > >> >The masking is applied to __get_user, __put_user, raw_copy_from_user, > > >> >raw_copy_to_user, clear_user, and the unsafe_* variants. > > >> > > > >> >Signed-off-by: Lukas Gerlach > > >> >--- > > >> > arch/riscv/include/asm/uaccess.h | 41 +++++++++++++++++++++++++------- > > >> > 1 file changed, 32 insertions(+), 9 deletions(-) > > >> > > > >> >diff --git a/arch/riscv/include/asm/uaccess.h b/arch/riscv/include/asm/uaccess.h > > >> >index 36bba6720c26..ceee1d62ff9b 100644 > > >> >--- a/arch/riscv/include/asm/uaccess.h > > >> >+++ b/arch/riscv/include/asm/uaccess.h > > >> >@@ -74,6 +74,23 @@ static inline unsigned long __untagged_addr_remote(struct mm_struct *mm, unsigne > > >> > #define __typefits(x, type, not) \ > > >> > __builtin_choose_expr(sizeof(x) <= sizeof(type), (unsigned type)0, not) > > >> > > > >> >+/* > > >> >+ * Sanitize a uaccess pointer such that it cannot reach any kernel address. > > >> >+ * > > >> >+ * On RISC-V, virtual addresses are sign-extended from the top implemented bit. > > >> >+ * User addresses have the MSB clear; kernel addresses have the MSB set. > > >> >+ * Clearing the MSB ensures any kernel pointer becomes non-canonical and will > > >> >+ * fault, while valid user pointers remain unchanged. > > >> >+ */ > > >> >+#define uaccess_mask_ptr(ptr) ((__typeof__(ptr))__uaccess_mask_ptr(ptr)) > > >> >+static inline void __user *__uaccess_mask_ptr(const void __user *ptr) > > >> >+{ > > >> >+ unsigned long val = (unsigned long)ptr; > > >> >+ > > >> >+ val = (val << 1) >> 1; > > >> >+ return (void __user *)val; > > >> > > >> This is only clearing b63 which is what we don't need here. > > > > > >It is also entirely the wrong operation. > > >A kernel address needs converting into an address that is guaranteed > > >to fault - not a user address that might be valid. > > > > This is about speculative accesses and not actual accesses. Due to some > > speculation it is possible that in speculative path a wrong address is > > generated with MSB=1. This simply ensures that bit is cleared for agen > > even in speculative path. > > You said you were following what x86 did - this isn't what is does. > Avoiding the conditional branch in access_ok() is actually a big win. > That is true even without the issues with speculative accesses to kernel > memory. > The 'address masking' (badly named - it isn't just masking) is a replacement > for access_ok(), it changes kernel addresses to invalid ones so that the > access faults and the trap/fault fixup code detects the error. If you can guarantee that address 0 is never mapped into userspace (not true for x86 for historic reasons) then I think you can convert kernel addresses to zero - which will then fault. This is simpler than using the base of the guard page (which is still needed for sequential accesses). Something like: addr &= (addr >= guard_page) - 1; will then work - but it needs (partially) coding in assembler to guarantee that 'setae' (or equivalent) is used rather than a conditional branch. David