[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230913125023.GG692@noisy.programming.kicks-ass.net>
Date: Wed, 13 Sep 2023 14:50:23 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Josh Poimboeuf <jpoimboe@...nel.org>
Cc: Nikolay Borisov <nik.borisov@...e.com>,
Andrew Cooper <andrew.cooper3@...rix.com>,
LKML <linux-kernel@...r.kernel.org>, x86@...nel.org,
Borislav Petkov <bp@...en8.de>,
Babu Moger <babu.moger@....com>, David.Kaplan@....com,
gregkh@...uxfoundation.org, Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH RFC 4/4] x86/srso: Use CALL-based return thunks to reduce
overhead
On Tue, Aug 22, 2023 at 03:18:28PM -0700, Josh Poimboeuf wrote:
> The problem is the call-site, not the thunk. Ideally we'd have an
> option which adds an INT3 after the 'JMP __x86_return_thunk'.
The -mharden-sls=all option *SHOULD* be extended to unconditionally emit
INT3 after everyt JMP instruction -- including the one used for
-mfunction-return=thunk-extern.
This is a known missing mitigation for an AMD SLS issue.
Due to the whole branch-type-confusion thing, AMD CPUs can predict the
JMP as 'not-a-branch' and continue to the next instruction.
I'm sure Andrew has the proper name and CVE stashed away somewhere. IIRC
he even has a GCC bugzilla entry for it.
Powered by blists - more mailing lists