On Fri, 14 Nov 2025 12:48:52 -0800 Linus Torvalds <[email protected]> wrote:
> On Fri, 14 Nov 2025 at 11:09, David Laight <[email protected]> > wrote: > > > > I think that is currently only x86-64? > > There are patches in the pipeline for ppc. > > I don't think I've seen anything for arm32 or arm64. > > Honestly, the fact that it's mainly true on x86-64 is simply because > that's the only architecture that has cared enough. > > Pretty much everybody else is affected by the exact same speculation > bugs. Sometimes the speculation window might be so small that it > doesn't matter, but in most cases it's just that the architecture is > so irrelevant that it doesn't matter. > > So no, this is not a "x86 only" issue. It might be a "only a couple of > architectures have cared enough for it to have any practical impact". > > End result: if some other architecture still has a __get_user() that > is noticeably faster than get_user(), it's not an argument for keeping > __get_user() - it's an argument that that architecture likely isn't > very important. I was really thinking it was a justification to get the 'address masking' implemented for other architectures. It wouldn't surprise me if some of the justifications for the 'guard page' at the top of x86-64 userspace (like speculative execution across the user-kernel boundary) aren't a more general problem. So adding support to arm32, arm64, riscV and 32bit x86 might be reasonable. What does that really leave? sparc, m68k? At that point requiring a guard page for all architectures starts looking reasonable, and the non 'address masking' user access checks can all be thrown away. That isn't going to happen quickly, but seems a reasonable aim. Architectures without speculation issues (old ones) can use a C compare. I think this works for 32bit x86 (without cmov): mov $-guard_page, %guard_off add %user_addr, %guard_off sbb %mask, %mask and %mask, %guard_off sub %guard_off, %user_addr mips-like architectures (no flags) probably require a 'cmp' and 'dec' to generate the mask value. (I'm not sure how that compares to any of the ppc asm blocks.) David > > Linus
