[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20241030045950.p6fc7xnkd3rq2gob@treble.attlocal.net>
Date: Tue, 29 Oct 2024 21:59:50 -0700
From: Josh Poimboeuf <jpoimboe@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: x86@...nel.org, linux-kernel@...r.kernel.org,
Thomas Gleixner <tglx@...utronix.de>,
Borislav Petkov <bp@...en8.de>,
Peter Zijlstra <peterz@...radead.org>,
Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>,
Waiman Long <longman@...hat.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Ingo Molnar <mingo@...hat.com>,
Michael Ellerman <mpe@...erman.id.au>,
linuxppc-dev@...ts.ozlabs.org,
Andrew Cooper <andrew.cooper3@...rix.com>,
Mark Rutland <mark.rutland@....com>,
"Kirill A . Shutemov" <kirill@...temov.name>
Subject: Re: [PATCH v3 1/6] x86/uaccess: Avoid barrier_nospec() in 64-bit
copy_from_user()
On Tue, Oct 29, 2024 at 04:03:31PM -1000, Linus Torvalds wrote:
> Hmm. So it strikes me that this still does the "access_ok()", but
> that's pointless for the actual pointer masking case. One of the whole
> points of the pointer masking is that we can just do this without
> actually checking the address (or length) at all.
>
> That's why the strncpy_from_user() has the pattern of
>
> if (can_do_masked_user_access()) {
> ... don't worry about the size of the address space ..
>
> and I think this code should do that too.
>
> IOW, I think we can do even better than your patch with something
> (UNTESTED!) like the attached.
>
> That will also mean that any other architecture that starts doing the
> user address masking trick will pick up on this automatically.
>
> Hmm?
Yeah, it makes sense to hook into that existing
can_do_masked_user_access() thing. The patch looks good, and it boots
without blowing up. Thanks!
Reviewed-by: Josh Poimboeuf <jpoimboe@...nel.org>
--
Josh
Powered by blists - more mailing lists