linux-kernel - Re: [RFC][PATCH 0/8] x86/mm: Simplify PAE page table handling

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] [day] [month] [year] [list]

Message-ID: <20250124085202.GC13226@noisy.programming.kicks-ass.net>
Date: Fri, 24 Jan 2025 09:52:02 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Dave Hansen <dave.hansen@...el.com>
Cc: Dave Hansen <dave.hansen@...ux.intel.com>, linux-kernel@...r.kernel.org,
	x86@...nel.org, tglx@...utronix.de, bp@...en8.de, joro@...tes.org,
	luto@...nel.org, kirill.shutemov@...ux.intel.com,
	rick.p.edgecombe@...el.com, jgross@...e.com
Subject: Re: [RFC][PATCH 0/8] x86/mm: Simplify PAE page table handling

On Thu, Jan 23, 2025 at 03:06:26PM -0800, Dave Hansen wrote:
> On 1/23/25 13:49, Peter Zijlstra wrote:

> > Can't we just rip it out?
> 
> 32-bit+PTI or 32-bit in general? ;)

Yes :-)

> I'm curious what Joerg and the other folks that worked on 32-bit PTI
> think about it in retrospect. The 32 vs. 64-bit security gap was
> probably modest in 2018 and it can only have grown since then.
> 
> I definitely haven't seen a lot of 32-bit PTI bug reports.

3db03fb4995e x86/mm: Fix pti_clone_entry_text() for i386
41e71dbb0e0a x86/mm: Fix pti_clone_pgtable() alignment assumption

Them cost me a few gray hairs :-)

Anyway, 32bit PTI is 'solid', it's just all the other speculation
mitigations what we've added to x86_64 only since.

Even the retpoline crap on i386, that is still vulnerable to the whole
funnel thing, so while it has the OG retpoline, it is still vulnerable
to more modern attacks that abuse the fact that all indirect jumps come
from only a single location.

So yes, we patches a few (early) holes on i386, but nobody should be
thinking i386 is 'secure' from all this speculation nonsense.

What's the point of having a few holes patched, if you're still bleeding
from a dozen others :/

So if we keep i386 around, it might just make sense to rip out all
speculation mitigations -- no point pretending.