From: Thomas Gleixner <tglx@linutronix.de>
To: David Laight <david.laight.linux@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
"Christophe Leroy" <christophe.leroy@csgroup.eu>,
"Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>,
"Andrew Cooper" <andrew.cooper3@citrix.com>,
"Linus Torvalds" <torvalds@linux-foundation.org>,
"kernel test robot" <lkp@intel.com>,
"Russell King" <linux@armlinux.org.uk>,
linux-arm-kernel@lists.infradead.org, x86@kernel.org,
"Madhavan Srinivasan" <maddy@linux.ibm.com>,
"Michael Ellerman" <mpe@ellerman.id.au>,
"Nicholas Piggin" <npiggin@gmail.com>,
linuxppc-dev@lists.ozlabs.org, "Paul Walmsley" <pjw@kernel.org>,
"Palmer Dabbelt" <palmer@dabbelt.com>,
linux-riscv@lists.infradead.org,
"Heiko Carstens" <hca@linux.ibm.com>,
"Christian Borntraeger" <borntraeger@linux.ibm.com>,
"Sven Schnelle" <svens@linux.ibm.com>,
linux-s390@vger.kernel.org,
"Julia Lawall" <Julia.Lawall@inria.fr>,
"Nicolas Palix" <nicolas.palix@imag.fr>,
"Peter Zijlstra" <peterz@infradead.org>,
"Darren Hart" <dvhart@infradead.org>,
"Davidlohr Bueso" <dave@stgolabs.net>,
"André Almeida" <andrealmeid@igalia.com>,
"Alexander Viro" <viro@zeniv.linux.org.uk>,
"Christian Brauner" <brauner@kernel.org>,
"Jan Kara" <jack@suse.cz>,
linux-fsdevel@vger.kernel.org
Subject: Re: [patch V3 07/12] uaccess: Provide scoped masked user access regions
Date: Tue, 21 Oct 2025 16:29:58 +0200 [thread overview]
Message-ID: <877bwoz5sp.ffs@tglx> (raw)
In-Reply-To: <20251020192859.640d7f0a@pumpkin>
On Mon, Oct 20 2025 at 19:28, David Laight wrote:
> On Fri, 17 Oct 2025 12:09:08 +0200 (CEST)
> Thomas Gleixner <tglx@linutronix.de> wrote:
> That definitely looks better than the earlier versions.
> Even if the implementation looks like an entry in the obfuscated C
> competition.
It has too many characters for that. The contest variant would be:
for(u8 s=0;!s;s=1)for(typeof(u) t= S(m,u,s,e);!s;s=1)for(C(u##m##a,c)(t);!s;s=1)for(const typeof(u) u=t;!s;s=1)
> I don't think you need the 'masked' in that name.
> Since it works in all cases.
>
> (I don't like the word 'masked' at all, not sure where it came from.
It's what Linus named it and I did not think about the name much so far.
> Probably because the first version used logical operators.
> 'Masking' a user address ought to be the operation of removing high-order
> address bits that the hardware is treating as 'don't care'.
> The canonical operation here is uaddr = min(uaddr, guard_page) - likely to be
> a conditional move.
That's how it's implemented for x86:
>> b84: 48 b8 ef cd ab 89 67 45 23 01 movabs $0x123456789abcdef,%rax
>> b8e: 48 39 c7 cmp %rax,%rdi
>> b91: 48 0f 47 f8 cmova %rax,%rdi
0x123456789abcdef is a compile time placeholder for $USR_PTR_MAX which is
replaced during early boot by the real user space topmost address. See below.
> I think that s/masked/sanitised/ would make more sense (the patch to do
> that isn't very big at the moment). I might post it.)
The real point is that it is optimized. It does not have to use the
speculation fence if the architecture supports "masking" because the CPU
can't speculate on the input address as the actual read/write address
depends on the cmova. That's similar to the array_nospec() magic which
masks the input index unconditionally so it's in the valid range before
it can be used for speculatively accessing the array.
So yes, the naming is a bit awkward.
In principle most places which use user_$MODE_access_begin() could
benefit from that. Also under the hood the scope magic actually falls
back to that when the architecture does not support the "masked"
variant.
So simply naming it scoped_user_$MODE_access() is probably the least
confusing of all.
>> If masked user access is enabled on an architecture, then the pointer
>> handed in to scoped_masked_user_$MODE_access() can be modified to point to
>> a guaranteed faulting user address. This modification is only scope local
>> as the pointer is aliased inside the scope. When the scope is left the
>> alias is not longer in effect. IOW the original pointer value is preserved
>> so it can be used e.g. for fixup or diagnostic purposes in the fault path.
>
> I think you need to add (in the kerndoc somewhere):
>
> There is no requirement to do the accesses in strict memory order
> (or to access the lowest address first).
> The only constraint is that gaps must be significantly less than 4k.
The requirement is that the access is not spilling over into the kernel
address space, which means:
USR_PTR_MAX <= address < (1U << 63)
USR_PTR_MAX on x86 is either
(1U << 47) - PAGE_SIZE (4-level page tables)
or (1U << 57) - PAGE_SIZE (5-level page tables)
Which means at least ~8 EiB of unmapped space in both cases.
The access order does not matter at all.
>> +#define __scoped_masked_user_access(_mode, _uptr, _size, _elbl) \
>> +for (bool ____stop = false; !____stop; ____stop = true) \
>> + for (typeof((_uptr)) _tmpptr = __scoped_user_access_begin(_mode, _uptr, _size, _elbl); \
>
> Can you use 'auto' instead of typeof() ?
Compilers are mightily unhappy about that unless I do typecasting on the
assignment, which is not really buying anything.
>> + !____stop; ____stop = true) \
>> + for (CLASS(masked_user_##_mode##_access, scope) (_tmpptr); !____stop; \
>> + ____stop = true) \
>> + /* Force modified pointer usage within the scope */ \
>> + for (const typeof((_uptr)) _uptr = _tmpptr; !____stop; ____stop = true) \
>
> gcc 15.1 also seems to support 'const auto _uptr = _tmpptr;'
Older compilers not so much.
Thanks,
tglx
next prev parent reply other threads:[~2025-10-21 14:30 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-17 10:08 [patch V3 00/12] uaccess: Provide and use scopes for user masked access Thomas Gleixner
2025-10-17 10:08 ` [patch V3 01/12] ARM: uaccess: Implement missing __get_user_asm_dword() Thomas Gleixner
2025-10-17 12:36 ` Mathieu Desnoyers
2025-10-17 10:08 ` [patch V3 02/12] uaccess: Provide ASM GOTO safe wrappers for unsafe_*_user() Thomas Gleixner
2025-10-17 12:43 ` Mathieu Desnoyers
2025-10-17 12:48 ` Mathieu Desnoyers
2025-10-17 10:09 ` [patch V3 03/12] x86/uaccess: Use unsafe wrappers for ASM GOTO Thomas Gleixner
2025-10-17 10:09 ` [patch V3 04/12] powerpc/uaccess: " Thomas Gleixner
2025-10-17 10:09 ` [patch V3 05/12] riscv/uaccess: " Thomas Gleixner
2025-10-17 10:09 ` [patch V3 06/12] s390/uaccess: " Thomas Gleixner
2025-10-17 10:09 ` [patch V3 07/12] uaccess: Provide scoped masked user access regions Thomas Gleixner
2025-10-17 11:08 ` Andrew Cooper
2025-10-17 11:21 ` Thomas Gleixner
2025-10-17 11:29 ` Andrew Cooper
2025-10-17 11:25 ` Peter Zijlstra
2025-10-17 13:23 ` Mathieu Desnoyers
2025-10-20 18:28 ` David Laight
2025-10-21 14:29 ` Thomas Gleixner [this message]
2025-10-21 14:42 ` Thomas Gleixner
2025-10-21 20:52 ` David Laight
2025-10-21 14:44 ` Peter Zijlstra
2025-10-21 15:06 ` Linus Torvalds
2025-10-21 15:45 ` Thomas Gleixner
2025-10-21 15:51 ` Linus Torvalds
2025-10-21 18:55 ` David Laight
2025-10-17 10:09 ` [patch V3 08/12] uaccess: Provide put/get_user_masked() Thomas Gleixner
2025-10-17 13:41 ` Mathieu Desnoyers
2025-10-17 13:45 ` Mathieu Desnoyers
2025-10-20 6:50 ` Thomas Gleixner
2025-10-17 10:09 ` [patch V3 09/12] [RFC] coccinelle: misc: Add scoped_masked_$MODE_access() checker script Thomas Gleixner
2025-10-17 10:51 ` Julia Lawall
2025-10-17 10:09 ` [patch V3 10/12] futex: Convert to scoped masked user access Thomas Gleixner
2025-10-17 10:09 ` [patch V3 11/12] x86/futex: " Thomas Gleixner
2025-10-17 13:37 ` Andrew Cooper
2025-10-17 10:09 ` [patch V3 12/12] select: " Thomas Gleixner
2025-10-17 10:35 ` Peter Zijlstra
2025-10-17 11:12 ` Thomas Gleixner
2025-10-17 10:37 ` [patch V3 00/12] uaccess: Provide and use scopes for user masked access Peter Zijlstra
2025-10-17 10:50 ` Andrew Cooper
2025-10-17 12:25 ` Mathieu Desnoyers
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=877bwoz5sp.ffs@tglx \
--to=tglx@linutronix.de \
--cc=Julia.Lawall@inria.fr \
--cc=andrealmeid@igalia.com \
--cc=andrew.cooper3@citrix.com \
--cc=borntraeger@linux.ibm.com \
--cc=brauner@kernel.org \
--cc=christophe.leroy@csgroup.eu \
--cc=dave@stgolabs.net \
--cc=david.laight.linux@gmail.com \
--cc=dvhart@infradead.org \
--cc=hca@linux.ibm.com \
--cc=jack@suse.cz \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=lkp@intel.com \
--cc=maddy@linux.ibm.com \
--cc=mathieu.desnoyers@efficios.com \
--cc=mpe@ellerman.id.au \
--cc=nicolas.palix@imag.fr \
--cc=npiggin@gmail.com \
--cc=palmer@dabbelt.com \
--cc=peterz@infradead.org \
--cc=pjw@kernel.org \
--cc=svens@linux.ibm.com \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
--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).