linux-kernel - Re: [PATCH net-next] vhost: use "checked" versions of get_user() and put

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] [day] [month] [year] [list]

Message-ID: <20251114213808.252fc8eb@pumpkin>
Date: Fri, 14 Nov 2025 21:38:08 +0000
From: David Laight <david.laight.linux@...il.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Jon Kohler <jon@...anix.com>, Jason Wang <jasowang@...hat.com>, "Michael
 S. Tsirkin" <mst@...hat.com>, Eugenio Pérez
 <eperezma@...hat.com>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
 "virtualization@...ts.linux.dev" <virtualization@...ts.linux.dev>,
 "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Borislav
 Petkov <bp@...en8.de>, Sean Christopherson <seanjc@...gle.com>
Subject: Re: [PATCH net-next] vhost: use "checked" versions of get_user()
 and put_user()

On Fri, 14 Nov 2025 12:48:52 -0800
Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> On Fri, 14 Nov 2025 at 11:09, David Laight <david.laight.linux@...il.com> 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