linux-kernel - Re: [PATCH] x86/uaccess: Zero the 8-byte get

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-=wj40jGrTES8SL69EVdtUwauL+C_12KGMpapdkDZEgjhiw@mail.gmail.com>
Date: Thu, 1 Aug 2024 09:24:02 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: David Gow <davidgow@...gle.com>
Cc: Kees Cook <kees@...nel.org>, Borislav Petkov <bp@...en8.de>, Thomas Gleixner <tglx@...utronix.de>, 
	Ingo Molnar <mingo@...hat.com>, Dave Hansen <dave.hansen@...ux.intel.com>, 
	Peter Zijlstra <peterz@...radead.org>, Andrew Morton <akpm@...ux-foundation.org>, 
	"H . Peter Anvin" <hpa@...or.com>, x86@...nel.org, kunit-dev@...glegroups.com, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86/uaccess: Zero the 8-byte get_range case on failure

On Wed, 31 Jul 2024 at 23:35, David Gow <davidgow@...gle.com> wrote:
>
> The 486 seemed to treat the wraparound a bit differently: it's triggering
> a General Protection Fault, and so giving the WARN() normally reserved
> for non-canonical addresses.

Ahh, yes. Old i386 machines (that we no longer support) did the same.
You hit the segment limit, not the page fault.

And we had something very similar when we did the whole 64-bit address
range checking relaxation (to avoid all the crazy LAM noise in the
access_ok() code).

See commit 6014bc27561f ("x86-64: make access_ok() independent of
LAM") and the extable.c parts in particular

That wasn't because of segment limits, but the whole "non-canonical
address range" ends up having a very similar situation, and also
causes #GP before the page fault.

So yeah, the same way x86-64 no longer warns for #GP in the user
address range and the point where the sign wraps, the 32-bit warning
for this #GP would have to be suppressed.

In fact, it's the exact same gp_fault_address_ok() logic, it would
just get a 32-bit case for "#GP at the end of the address range is
ok".

> So I'm a little worried that there might be more cases where this works
> differently. Does anyone know for sure if it's worth risking it?

I don't think the address wrap-around is a risk per se.

As far as I know the "undefined behavior" is not some kind of subtle
thing where things have gone wrong in the past - it's just that later
microarchitectures just ended up special-casing the flat segment setup
and no longer do any segment limit checks (or base additions) at all.

But I'm also not going to argue that this is really worth pursuing on
32-bit if anybody is in the least worried.

It's on life support, not like it's actively maintained. Your original
patch may not be exactly "pretty", but it clearly fixes the problem
without playing any games.

          Linus