linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: David Laight <david.laight.linux@gmail.com>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>,
	Michael Ellerman <mpe@ellerman.id.au>,
	 Nicholas Piggin <npiggin@gmail.com>,
	Naveen N Rao <naveen@kernel.org>,
	 Madhavan Srinivasan <maddy@linux.ibm.com>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	 Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
	Thomas Gleixner <tglx@linutronix.de>,
	 Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	 Darren Hart <dvhart@infradead.org>,
	Davidlohr Bueso <dave@stgolabs.net>,
	 Andre Almeida <andrealmeid@igalia.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	 Dave Hansen <dave.hansen@linux.intel.com>,
	linux-kernel@vger.kernel.org,  linuxppc-dev@lists.ozlabs.org,
	linux-fsdevel@vger.kernel.org,  linux-mm@kvack.org
Subject: Re: [PATCH 5/5] powerpc: Implement masked user access
Date: Sun, 22 Jun 2025 10:40:00 -0700	[thread overview]
Message-ID: <CAHk-=wgvyNdkYHWfL5NxK=k1DCdtyuHCMFZsbQ5FyP3KNvDNPw@mail.gmail.com> (raw)
In-Reply-To: <20250622181351.08141b50@pumpkin>

On Sun, 22 Jun 2025 at 10:13, David Laight <david.laight.linux@gmail.com> wrote:
>
> Not checking the size is slightly orthogonal.
> It really just depends on the accesses being 'reasonably sequential'.
> That is probably always true since access_ok() covers a single copy.

It is probably true in practice, but yeah, it's worth thinking about.
Particularly for various user level structure accesses, we do end up
often accessing the members individually and thus potentially out of
order, but as you say "reasonable sequential" is still true: the
accesses are within a reasonably small offset of each other.

And when we have potentially very big accesses with large offsets from
the beginning (ie things like read/write() calls), we do them
sequentially.

There *might* be odd ioctls and such that get offsets from user space,
though. So any conversion to using 'masked_user_access_begin()' needs
to have at least *some* thought and not be just a mindless conversion
from access_ok().

We have this same issue in access_ok() itself, and on x86-64 that does

  static inline bool __access_ok(const void __user *ptr, unsigned long size)
  {
        if (__builtin_constant_p(size <= PAGE_SIZE) && size <= PAGE_SIZE) {
                return valid_user_address(ptr);
        .. do the more careful one that actually uses the 'size' ...

so it turns access_ok() itself into just a simple single-ended
comparison with the starting address for small sizes, because we know
it's ok to overflow by a bit (because of how valid_user_address()
works on x86).

           Linus


  reply	other threads:[~2025-06-22 17:46 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-22  9:52 [PATCH 0/5] " Christophe Leroy
2025-06-22  9:52 ` [PATCH 1/5] uaccess: Add masked_user_{read/write}_access_begin Christophe Leroy
2025-06-22 16:35   ` David Laight
2025-06-24  5:34     ` Christophe Leroy
2025-06-22  9:52 ` [PATCH 2/5] uaccess: Add speculation barrier to copy_from_user_iter() Christophe Leroy
2025-06-22 16:52   ` David Laight
2025-06-22 16:57   ` Linus Torvalds
2025-06-22 20:18     ` David Laight
2025-06-24  5:49     ` Christophe Leroy
2025-06-24  8:07       ` David Laight
2025-06-24 15:15       ` Linus Torvalds
2025-06-22  9:52 ` [PATCH 3/5] powerpc: Remove unused size parametre to KUAP enabling/disabling functions Christophe Leroy
2025-06-22  9:52 ` [PATCH 4/5] powerpc: Move barrier_nospec() out of allow_read_{from/write}_user() Christophe Leroy
2025-06-22  9:52 ` [PATCH 5/5] powerpc: Implement masked user access Christophe Leroy
2025-06-22 17:13   ` David Laight
2025-06-22 17:40     ` Linus Torvalds [this message]
2025-06-22 19:51       ` David Laight
2025-06-22 18:57     ` Segher Boessenkool
2025-06-22 16:20 ` [PATCH 0/5] " David Laight
2025-06-24  5:27   ` Christophe Leroy
2025-06-24  8:32     ` David Laight
2025-06-24 21:37       ` Segher Boessenkool
2025-06-25  8:30         ` David Laight
2025-06-24 13:17     ` Segher Boessenkool
2025-06-24 16:50       ` David Laight
2025-06-24 18:25         ` Segher Boessenkool
2025-06-24 21:08           ` David Laight
2025-06-26  5:56             ` Christophe Leroy
2025-06-26 22:01               ` Segher Boessenkool
2025-07-05 10:55                 ` Christophe Leroy
2025-07-05 11:42                   ` Segher Boessenkool
2025-07-05 18:33                 ` David Laight
2025-07-05 20:15                   ` Segher Boessenkool
2025-07-05 21:05                     ` David Laight
2025-07-05 21:37                       ` Segher Boessenkool
2025-06-26 21:39             ` Segher Boessenkool

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='CAHk-=wgvyNdkYHWfL5NxK=k1DCdtyuHCMFZsbQ5FyP3KNvDNPw@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=andrealmeid@igalia.com \
    --cc=brauner@kernel.org \
    --cc=christophe.leroy@csgroup.eu \
    --cc=dave.hansen@linux.intel.com \
    --cc=dave@stgolabs.net \
    --cc=david.laight.linux@gmail.com \
    --cc=dvhart@infradead.org \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=maddy@linux.ibm.com \
    --cc=mingo@redhat.com \
    --cc=mpe@ellerman.id.au \
    --cc=naveen@kernel.org \
    --cc=npiggin@gmail.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=viro@zeniv.linux.org.uk \
    /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