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,URIBL_BLOCKED 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 AD5BBC433C1 for ; Wed, 24 Mar 2021 07:54:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5C95D619FE for ; Wed, 24 Mar 2021 07:54:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230018AbhCXHx5 (ORCPT ); Wed, 24 Mar 2021 03:53:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48458 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232783AbhCXHxs (ORCPT ); Wed, 24 Mar 2021 03:53:48 -0400 Received: from desiato.infradead.org (desiato.infradead.org [IPv6:2001:8b0:10b:1:d65d:64ff:fe57:4e05]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3F05EC061763 for ; Wed, 24 Mar 2021 00:53:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=d/OEztyvqrSXfzAQn7WwsuIQVa9syZaS4bN64rFmwV8=; b=GI+DYg7lhlpgTS0X4uWIm4dvnh 02JCAfbb2MuYLgmozjwKqjbSHlbW+oCmbVzHlcYtIjh4MWnE1zElRxC8wHozAzbpj1PLYVMCtDl/A 0a9zxnXtSV7z4vvbqfF84XkFctTf8CGOyo0CvMB0GTTyZPjyIqEfeKzElzC9GZmdRAb+Wk/e8Rc7P HJYbKwZoQgs5ODqwHKT32xtkrTxO0CuMVysIb1Yw+UE+pO+D51HdcGoaKLMGPIpWZr+KVq7Z25VsH hR9Hbfj9WKGmU6WVIHVZ4+viX9JKy8s+epLd+I06uXXlwk6asrSS97aLMiX4fM4VnhIvlTFAoamhx JN7fg2/g==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.94 #2 (Red Hat Linux)) id 1lOyJp-00GWQA-NW; Wed, 24 Mar 2021 07:52:45 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 40A3F301A7A; Wed, 24 Mar 2021 08:52:44 +0100 (CET) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 29F502360188E; Wed, 24 Mar 2021 08:52:44 +0100 (CET) Date: Wed, 24 Mar 2021 08:52:44 +0100 From: Peter Zijlstra To: Nick Desaulniers Cc: Andrew Cooper , Will Deacon , 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 , Jian Cai , Luis Lozano , Kristof Beyls Subject: Re: Plumbers CF MCs Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-toolchains@vger.kernel.org On Tue, Mar 23, 2021 at 03:26:29PM -0700, Nick Desaulniers wrote: > On Tue, Mar 23, 2021 at 12:29 PM 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. > > > > 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.