linux-kernel - Re: [PATCH 1/2] riscv: Use pointer masking to limit uaccess speculation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aVB8wLSgmE7IRo7e@debug.ba.rivosinc.com>
Date: Sat, 27 Dec 2025 16:41:36 -0800
From: Deepak Gupta <debug@...osinc.com>
To: Lukas Gerlach <lukas.gerlach@...pa.de>
Cc: linux-riscv@...ts.infradead.org, palmer@...belt.com, pjw@...nel.org,
	aou@...s.berkeley.edu, alex@...ti.fr, linux-kernel@...r.kernel.org,
	daniel.weber@...pa.de, michael.schwarz@...pa.de,
	marton.bognar@...euven.be, jo.vanbulck@...euven.be
Subject: Re: [PATCH 1/2] riscv: Use pointer masking to limit uaccess
 speculation

On Sat, Dec 27, 2025 at 01:57:03PM +0100, Lukas Gerlach wrote:
>Thanks for the review. You're right - we should only clear the sign bit
>(b38/b47/b56 depending on mode), not b63. Clearing upper bits would
>interfere with pointer masking.
>
>Here's a fix that computes the sign bit position arithmetically to avoid
>branches, this ensures the mitigation cannot be bypassed under speculation.
>This is basically the VA_BITS macro but computed in a branch-free way.
>
>In arch/riscv/include/asm/uaccess.h:
>
>  #define UACCESS_SIGN_BIT \
>      (VA_BITS_SV39 - 1 + 9*((unsigned long)pgtable_l4_enabled) + \
>       9*((unsigned long)pgtable_l5_enabled))
>
>  #define uaccess_mask_ptr(ptr) ((__typeof__(ptr))__uaccess_mask_ptr(ptr))
>  static inline void __user *__uaccess_mask_ptr(const void __user *ptr)
>  {
>      return (void __user *)((unsigned long)ptr & ~BIT_ULL(UACCESS_SIGN_BIT));
>  }
>
>This evaluates to bit 38 for Sv39, bit 47 for Sv48, and bit 56 for Sv57.

looks good to me.
Although, I am concerned about maintainibility and bit-rotting.
I would suggest to fix VA_BITS definition instead of defining a new macro here.