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
next prev parent 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).