From: Peter Zijlstra <peterz@infradead.org>
To: Dave Hansen <dave.hansen@intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>,
linux-kernel@vger.kernel.org, x86@kernel.org, tglx@linutronix.de,
bp@alien8.de, joro@8bytes.org, luto@kernel.org,
kirill.shutemov@linux.intel.com, rick.p.edgecombe@intel.com,
jgross@suse.com
Subject: Re: [RFC][PATCH 0/8] x86/mm: Simplify PAE page table handling
Date: Fri, 24 Jan 2025 09:52:02 +0100 [thread overview]
Message-ID: <20250124085202.GC13226@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <6c1785c8-e74e-4912-95bb-88b6e94f544f@intel.com>
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.
next prev parent reply other threads:[~2025-01-24 8:52 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-23 17:24 [RFC][PATCH 0/8] x86/mm: Simplify PAE page table handling Dave Hansen
2025-01-23 17:24 ` [RFC][PATCH 1/8] x86/mm: Always allocate a whole page for PAE PGDs Dave Hansen
2025-01-23 17:24 ` [RFC][PATCH 2/8] x86/mm: Always "broadcast" PMD setting operations Dave Hansen
2025-01-23 17:24 ` [RFC][PATCH 3/8] x86/mm: Always tell core mm to sync kernel mappings Dave Hansen
2025-01-23 17:24 ` [RFC][PATCH 4/8] x86/mm: Simplify PAE PGD sharing macros Dave Hansen
2025-01-23 17:24 ` [RFC][PATCH 5/8] x86/mm: Fix up comments around PMD preallocation Dave Hansen
2025-01-23 17:24 ` [RFC][PATCH 6/8] x86/mm: Preallocate all PAE page tables Dave Hansen
2025-01-23 17:24 ` [RFC][PATCH 7/8] x86/mm: Remove duplicated PMD preallocation macro Dave Hansen
2025-01-23 17:24 ` [RFC][PATCH 8/8] x86/mm: Remove now unused SHARED_KERNEL_PMD Dave Hansen
2025-01-23 21:49 ` [RFC][PATCH 0/8] x86/mm: Simplify PAE page table handling Peter Zijlstra
2025-01-23 23:06 ` Dave Hansen
2025-01-24 7:58 ` Joerg Roedel
2025-01-24 19:12 ` Dave Hansen
2025-01-28 8:13 ` Joerg Roedel
2025-01-24 8:52 ` Peter Zijlstra [this message]
2025-02-24 18:55 ` Ingo Molnar
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=20250124085202.GC13226@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=jgross@suse.com \
--cc=joro@8bytes.org \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=rick.p.edgecombe@intel.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/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