linux-kernel - Re: [PATCH 1/1] mm: Remove the access_ok() call from gup_fast

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHk-=wgecfFK=fDpk6+-C_gNOnzRKhO5wwuB7V396GwTRBhBJQ@mail.gmail.com>
Date: Sun, 9 Feb 2025 11:43:08 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: David Laight <david.laight.linux@...il.com>
Cc: Jason Gunthorpe <jgg@...dia.com>, Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org, 
	linux-kernel@...r.kernel.org, x86@...nel.org, Jan Kara <jack@...e.cz>, 
	John Hubbard <jhubbard@...dia.com>, Peter Xu <peterx@...hat.com>, 
	Dave Hansen <dave.hansen@...ux.intel.com>, Andy Lutomirski <luto@...nel.org>, 
	Peter Zijlstra <peterz@...radead.org>, Thomas Gleixner <tglx@...utronix.de>, 
	Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>
Subject: Re: [PATCH 1/1] mm: Remove the access_ok() call from gup_fast_fallback().

On Sun, 9 Feb 2025 at 11:00, David Laight <david.laight.linux@...il.com> wrote:
>
> They still do 'stuff' and end up containing a slow memory synchronising
> instruction (to avoid speculative accesses controlled by the application).
>
> But there are better ways to handle bad user pointers.

Not always. If you use __get_user() and friends, you basically *have*
to use access_ok(), or you have to be playing games (like some tracing
code does, which actually wants to use it as a "I want a kernel
pointer _or_ a user pointer{".

Now, admittedly probably nobody should be using __get_user() and
friends any more. Almost all the reasons for using it are entirely
historical and just not true any more.

But also, comparing against TASK_SIZE_MAX isn't actually the same as
access_ok() historically. We've moved in that direction, yes, but we
very much used to have a distinction between "this is the fixed
maximum", and "this is the actual run-time size".

We've moved towards just using TASK_SIZE_MAX mainly because the
run-time size check was annoyingly expensive is some pretty critical
code.

But historically the TASK_SIZE_MAX thing is the "this is fast but not
exact, use it only for special code that knows what it is doing", and
"access_ok()" was "this is proper"

> So, mostly access_ok() isn't needed outside the architecture code
> that handles userspace accesses.

Oh, there is still a fair amount of code that really does need it.

Admittedly most of it should either be converted to just using regular
get/put_user(), or into the modern "user_access_begin()" model, but we
do have a number of __get/put_user() users that still very much need
that access_ok().

And anything that follows page tables had better check that it's
proper. But in that case, I do believe checking for TASK_SIZE_MAX
tends to be equivalent.

              Linus