[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20211103083559.GB174703@worktop.programming.kicks-ass.net>
Date: Wed, 3 Nov 2021 09:35:59 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Andy Lutomirski <luto@...nel.org>
Cc: Kees Cook <keescook@...omium.org>,
Ard Biesheuvel <ardb@...nel.org>,
Sami Tolvanen <samitolvanen@...gle.com>,
Mark Rutland <mark.rutland@....com>,
the arch/x86 maintainers <x86@...nel.org>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Nathan Chancellor <nathan@...nel.org>,
Nick Desaulniers <ndesaulniers@...gle.com>,
Sedat Dilek <sedat.dilek@...il.com>,
Steven Rostedt <rostedt@...dmis.org>,
linux-hardening@...r.kernel.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
llvm@...ts.linux.dev
Subject: Re: [PATCH] static_call,x86: Robustify trampoline patching
On Tue, Nov 02, 2021 at 05:20:05PM -0700, Andy Lutomirski wrote:
> I think that's a big mistake -- any sane ENDBR-using scheme would
> really prefer that ENDBR to be right next to the actual function body,
> and really any scheme would benefit due to better cache locality.
Agreed, IBT/BTI want the landing pad in front of the actual function.
> But, more importantly, IMO any sane ENDBR-using scheme wants to
> generate the indirect stub as part of code gen for the actual
> function.
Sorta, I really want to be able to not have a landing pad for functions
whose address is never taken. At that point it doesn't matter if it gets
generated along with the function and then stripped/poisoned later, or
generated later.
As such, the landing pad should not be part of the function proper,
direct calls should never observe it.
Less landing pads is more better.
Powered by blists - more mailing lists