netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Laight <david.laight.linux@gmail.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "Jon Kohler" <jon@nutanix.com>,
	"Jason Wang" <jasowang@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Eugenio Pérez" <eperezma@redhat.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"virtualization@lists.linux.dev" <virtualization@lists.linux.dev>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Borislav Petkov" <bp@alien8.de>,
	"Sean Christopherson" <seanjc@google.com>
Subject: Re: [PATCH net-next] vhost: use "checked" versions of get_user() and put_user()
Date: Fri, 14 Nov 2025 21:38:08 +0000	[thread overview]
Message-ID: <20251114213808.252fc8eb@pumpkin> (raw)
In-Reply-To: <CAHk-=whJ0T_0SMegsbssgtWgO85+nJPapn6B893JQkJ7x6K0Kw@mail.gmail.com>

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

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


  reply	other threads:[~2025-11-14 21:38 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-13  0:55 [PATCH net-next] vhost: use "checked" versions of get_user() and put_user() Jon Kohler
2025-11-13  1:09 ` Jason Wang
2025-11-14 14:53   ` Jon Kohler
2025-11-14 17:48     ` Linus Torvalds
2025-11-14 19:08       ` David Laight
2025-11-14 20:48         ` Linus Torvalds
2025-11-14 21:38           ` David Laight [this message]
2025-11-17  4:32     ` Jason Wang
2025-11-17 17:34       ` Jon Kohler
2025-11-20  1:57         ` Jason Wang
2025-11-25 19:45           ` Jon Kohler
2025-11-26  6:04             ` Jason Wang
2025-11-26 10:25               ` Arnd Bergmann
2025-11-26 19:47                 ` Jon Kohler
2025-11-26 19:58                   ` Arnd Bergmann
2025-11-26 21:42                     ` Jon Kohler
2025-11-26 21:45                       ` Linus Torvalds
2025-11-27  2:58                         ` Jon Kohler
2025-11-27  1:08                   ` Jason Wang
2025-11-27  3:11                     ` Jon Kohler
2025-11-27  6:31                       ` Michael S. Tsirkin
2025-11-27  6:32                       ` Michael S. Tsirkin
2025-12-02 16:54                         ` Jon Kohler
2025-11-14 18:54 ` David Laight
2025-11-14 19:30   ` Jon Kohler
2025-11-14 20:32     ` David Laight
2025-11-16  6:32     ` Michael S. Tsirkin

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=20251114213808.252fc8eb@pumpkin \
    --to=david.laight.linux@gmail.com \
    --cc=bp@alien8.de \
    --cc=eperezma@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=jon@nutanix.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=seanjc@google.com \
    --cc=torvalds@linux-foundation.org \
    --cc=virtualization@lists.linux.dev \
    /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).