From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8CDE2C433F5 for ; Tue, 19 Oct 2021 18:00:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6610B6136A for ; Tue, 19 Oct 2021 18:00:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234517AbhJSSCo (ORCPT ); Tue, 19 Oct 2021 14:02:44 -0400 Received: from mail-40133.protonmail.ch ([185.70.40.133]:64464 "EHLO mail-40133.protonmail.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230158AbhJSSCm (ORCPT ); Tue, 19 Oct 2021 14:02:42 -0400 Date: Tue, 19 Oct 2021 18:00:22 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail; t=1634666423; bh=jAndP/ZdC+GdpA1dIsp1nEY8S4dGqOR03D236U+cg9U=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=YwEGi0vJYFZp4zisZRBbTWrO8PhaRaSfdDssCEgfvNER+bmXLS5s2a2j0iT0xRx29 Z+xoof5muWVZCUoPwhiqLFtqQNvc0VYXqCyAev5ExYxSHuB2VySoPeGdTpglIy5kEd 4ONaQ0RXcNJBcPOu+vN3jQ4kwBDP9E9D4f72GTn4Yw+tDLHKEyW0mhkaAlEangda2S scJX1hxWlCLfepqOBWfvXccEzlg7BVTBV59J6+toPTf8I/YMevgFc4fZtFyOeLv16Z ZTAqyGvB9EeLPiMXjkPelc47Oq6RbIlAHAq3hutYpWu2KjdP3jbqd5MRDnOzqQnjzB xJjFhzBmQmJag== To: Sami Tolvanen From: Alexander Lobakin Cc: Alexander Lobakin , Peter Zijlstra , Borislav Petkov , X86 ML , Josh Poimboeuf , andrew.cooper3@citrix.com, LKML , alexei.starovoitov@gmail.com, Nick Desaulniers Reply-To: Alexander Lobakin Subject: Re: [PATCH 4/9] x86/alternative: Implement .retpoline_sites support Message-ID: <20211019175336.169584-1-alobakin@pm.me> In-Reply-To: References: <20211013122217.304265366@infradead.org> <20211013123645.002402102@infradead.org> <20211015165635.GH174703@worktop.programming.kicks-ass.net> <20211018225905.86034-1-alobakin@pm.me> <20211019001845.85256-1-alobakin@pm.me> <20211019094038.80569-1-alobakin@pm.me> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Sami Tolvanen Date: Tue, 19 Oct 2021 08:37:14 -0700 > On Tue, Oct 19, 2021 at 3:17 AM Peter Zijlstra wro= te: > > > > > > + Sami > > > > (Sami, for context: > > > > https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git/log/= ?h=3Dobjtool/core > > > > which contains the following code: > > > > + void (*target)(void); > > + int reg, i =3D 0; > > + > > + target =3D addr + insn->length + insn->immediate.value; > > + reg =3D (target - &__x86_indirect_thunk_rax) / > > + (&__x86_indirect_thunk_rcx - &__x86_indirect_thunk_rax); > > + > > + if (WARN_ON_ONCE(reg & ~0xf)) > > + return -1; > > > > which blows up something fierce on clang-cfi) > > > > On Tue, Oct 19, 2021 at 09:47:26AM +0000, Alexander Lobakin wrote: > > > > > Oh okay, it's because of ClangCFI: > > > > > > SMP alternatives: You were looking for __typeid__ZTSFvvE_global_addr+= 0x370/0x1410 at 0xffffffffa523cd60,> > > > SMP alternatives: rax is __typeid__ZTSFvvE_global_addr+0x360/0x1410 a= t 0xffffffffa523cd50 > > > > > > Sorry for confusing, seems like it's a side effect of using it on > > > Clang 12 while the original series supports only 13+. I'll double > > > check and let know if find something. > > > > I'm thinking CFI will totally screw this up regardless, seeing how a > > function pointer is taken, and the CFI magicks will turn that into one > > of those weird trampolines instead of the actual symbol. > > > > The compiler could of course deduce that these addresses are never > > called and don't escape the function, and therefore doesn't need to do > > the CFI transformation on then, but I'm guessing it isn't quite that > > clever. > > Yes, it's unfortunately not that clever. > > > Also doing CFI on retpoline thunks seems 'weird', they have a very > > particular calling convention, excplicitly very much not the standard C > > one. Can't we mark them using asmlinkage or something to tell the > > compiler to politely 'bugger off' or somesuch ;-) > > I confirmed that using an opaque type for the thunk declaration fixes > this issue with CFI. It also makes it obvious that these are not > callable from C code. Oh, glad we caught this then, much thanks y'all! > Sami Thanks, Al