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.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 BA0C1C433C1 for ; Tue, 23 Mar 2021 19:56:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 84809619C8 for ; Tue, 23 Mar 2021 19:56:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231244AbhCWT4K (ORCPT ); Tue, 23 Mar 2021 15:56:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35392 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230224AbhCWTzu (ORCPT ); Tue, 23 Mar 2021 15:55:50 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 60854C061574 for ; Tue, 23 Mar 2021 12:55:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=Upb8jbPwMQIHuck9u8dih3xws9+N9Y2t9/p2ByFzkIQ=; b=N8+8+VaDLvJK2BWmPL1bcXJCxx w9k6Itq3RWp3jboPWp9mFBYKMEbpdB2EwhCJbkZH+ZGVaigHqr97Qj9CliWnVPe3yjrZLuGXtY+j9 0FArsmYR7ScBIeT8NKazCMr8N4J0xISrX+LVG4VfMY1lwBp6+77c94pFRIX7BYsjgPD21IkDzzIsl /nDw5p9CduJoY7MD5GKvGMlatY/6eNRftPdM7Gr73NEf2Zzz2Z6mcPuLxPewo7pxVX/rE3BmAZiUm p0uRzT9rkeFBEek8FmcCze5KzQL2NBF47fyltOPQ04sCfWvOVg4rT+O2VakPFihVHaTehm9fqMjAC 6hBVLQjA==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=worktop.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.94 #2 (Red Hat Linux)) id 1lOn6D-00AU6t-OS; Tue, 23 Mar 2021 19:54:05 +0000 Received: by worktop.programming.kicks-ass.net (Postfix, from userid 1000) id E19359864FF; Tue, 23 Mar 2021 20:53:58 +0100 (CET) Date: Tue, 23 Mar 2021 20:53:58 +0100 From: Peter Zijlstra To: Andrew Cooper Cc: 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, Segher Boessenkool , Josh Poimboeuf , Will Deacon Subject: Re: Plumbers CF MCs Message-ID: <20210323195358.GB4746@worktop.programming.kicks-ass.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-toolchains@vger.kernel.org On Tue, Mar 23, 2021 at 07:29:01PM +0000, Andrew Cooper 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. Yep, just making sure it doesn't get lost. > 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. For CALL we can follow with LFENCE (hurts), or if we can get a limit on how many instructions deep the speculation gap is, a bunch of NOPs. Or possibly nothing at all. As such it might make sense to have these two cases separated out. Another utterly disguisting option is to align all CALL instructions on 8 bytes and have it followed by 3 INT3s to make it 8 bytes long. Then have every function prologue round up the return address. This should work with tail-call optimizations because the round-up is NOP when repeated. The obvious down-side is that it will utterly wreck the RSB For unaffected chips we could then NOP both the trailing INT3s and the alignment prologue at runtime. > Having some toolchain support to deal with > this would be great, and preferable to some of the asm hackary currently > under suggestion. Agreed, hence the inclusion in this list.