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 X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C957DC433ED for ; Fri, 2 Apr 2021 12:47:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7EF536113D for ; Fri, 2 Apr 2021 12:47:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235426AbhDBMr0 (ORCPT ); Fri, 2 Apr 2021 08:47:26 -0400 Received: from gate.crashing.org ([63.228.1.57]:53904 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235304AbhDBMrZ (ORCPT ); Fri, 2 Apr 2021 08:47:25 -0400 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 132CeWKx007096; Fri, 2 Apr 2021 07:40:33 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 132CeVrf007089; Fri, 2 Apr 2021 07:40:31 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Fri, 2 Apr 2021 07:40:31 -0500 From: Segher Boessenkool To: Peter Zijlstra Cc: Andrew Cooper , Nick Desaulniers , linux-toolchains@vger.kernel.org, clang-built-linux , Steven Rostedt , "Jose E. Marchesi" , Kees Cook , Florian Weimer , Christian Brauner , nick.alcock@oracle.com, Josh Poimboeuf , Will Deacon Subject: Re: Plumbers CF MCs Message-ID: <20210402124031.GH13863@gate.crashing.org> References: <20210323195358.GB4746@worktop.programming.kicks-ass.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210323195358.GB4746@worktop.programming.kicks-ass.net> User-Agent: Mutt/1.4.2.3i Precedence: bulk List-ID: X-Mailing-List: linux-toolchains@vger.kernel.org On Tue, Mar 23, 2021 at 08:53:58PM +0100, Peter Zijlstra wrote: > On Tue, Mar 23, 2021 at 07:29:01PM +0000, Andrew Cooper wrote: > > 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.  > > So JMP and RET can trivially have INT3 following in such a way that that > instruction is never in the actual execution path. This is obviously not > possible for CALL. What about call ; jmp 0f ; int3 ; 0: ? Only the jmp can be speculatively executed (if your (u)arch executes jumps at all), but that cannot be a problem, no data is involved. > > Having some toolchain support to deal with > > this would be great, and preferable to some of the asm hackary currently > > under suggestion. I fail to see how it is anything more than some boring backend-specific patches? By nature you pretty much have to emit this as canned instruction sequences, so all the rest of the compiler sees it is just a call or jump or whathaveyou. Segher