Re: Plumbers CF MCs

From: Peter Zijlstra <peterz@infradead.org>
To: Nick Desaulniers <ndesaulniers@google.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Will Deacon <will@kernel.org>,
	linux-toolchains@vger.kernel.org,
	clang-built-linux <clang-built-linux@googlegroups.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	"Jose E. Marchesi" <jemarch@gnu.org>,
	Kees Cook <keescook@chromium.org>,
	Florian Weimer <fweimer@redhat.com>,
	Christian Brauner <christian.brauner@canonical.com>,
	nick.alcock@oracle.com,
	Segher Boessenkool <segher@kernel.crashing.org>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Jian Cai <jiancai@google.com>, Luis Lozano <llozano@google.com>,
	Kristof Beyls <Kristof.Beyls@arm.com>
Subject: Re: Plumbers CF MCs
Date: Wed, 24 Mar 2021 08:52:44 +0100	[thread overview]
Message-ID: <YFrvzKHoyxQekdal@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <CAKwvOdkk6bwJh22L51F0DAMuFXJYKUTjbzQV+STD2h35Z7_vQA@mail.gmail.com>

On Tue, Mar 23, 2021 at 03:26:29PM -0700, Nick Desaulniers wrote:
> On Tue, Mar 23, 2021 at 12:29 PM Andrew Cooper
> <andrew.cooper3@citrix.com> wrote:
> >
> > On 23/03/2021 08:35, Peter Zijlstra wrote:
> > > There also is talk about straight line speculation mitigations. for x86
> > > we should probably emit an INT3 after every JMP and RET. Although this
> > > might not be controversial and be sorted by the time Plumbers happens.
> >
> > I guess this one is levied at me.
> >
> > Hopefully it isn't controversial in any way.  I have just had sufficient
> > tuits to get around to making an x86 straight line speculation feature
> > request to the GCC and Clang communities yet.
> >
> > For the compiler folk here, the tl;dr is that indirect CALL/JMP (i.e.
> > function pointers, jump tables) and RET instructions may speculatively
> > execute the next sequential instruction(s) before taking the control
> > flow change into account.  Having some toolchain support to deal with
> > this would be great, and preferable to some of the asm hackary currently
> > under suggestion.
> 
> There is some prior art here, for ARM in -fharden-sls=*.
> https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/downloads/straight-line-speculation

Yes, I'm aware of that.

> It's not clear from the kernel thread that the existing compiler
> mitigations are amenable with live patching in/out mitigations for
> hardware that is affected or not, respectively.
> https://lore.kernel.org/lkml/20210305095256.GA22536@willie-the-truck/

ARM64 doesn't (yet) have objtool. Using objtool I could easily generate
a sites list to patch out things.

That said, the JMP,RET things don't need patching out (ARM's retbr
option) they're never on the execution path. It's the CALL thing (blr)
that would need runtime tinkering.

But I appreciate Will's stance; it would be very good to have a thread
analysis vs Spectre-v1.

> Perhaps worth a discussion on the mailing list in
> https://www.kernel.org/doc/html/latest/admin-guide/security-bugs.html ?

All of this is public by now, hence security@k.org isn't interested.