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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A36BFEE4993 for ; Mon, 21 Aug 2023 15:16:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234897AbjHUPQm (ORCPT ); Mon, 21 Aug 2023 11:16:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45806 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232461AbjHUPQl (ORCPT ); Mon, 21 Aug 2023 11:16:41 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BBF4DBC for ; Mon, 21 Aug 2023 08:16:39 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 52559618BF for ; Mon, 21 Aug 2023 15:16:39 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 569DCC433C7; Mon, 21 Aug 2023 15:16:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1692630998; bh=nUnU/eJw/z9XobglMFHWX2PLQc8tDxd8PnG9xVDrNMM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Xvm+zFeGlkMPyi44ipywMGXKv+td3w/wTME4lXKMwwET/vFj7uvXdU7lShLp608fC r5TubIkOyUzZdt2wJCQuZGpNH3sVnnTd/2SQU76EvhQ53kiG7hGlR6i7XVj/FQuAXe e5afWao1gRyk2sunG8nFTg8/morcutQRJ2dW93g9YT2CHncDK9+isCRniu0lsTv/tx 8l9prKjL2/1Xx/gvQ7sCYBXNXO+xaBLoHlMzQSzJCIek15Lgo5wsdkB8PghGbHHhY7 8v/ZdKXPpvdW9rgzNaBQ3mdsax6ljtlaAGwOJ7GBhq3PYkOjtRVeU825va6ntB9dkI dASGOJEvZ9Ecw== Date: Mon, 21 Aug 2023 08:16:36 -0700 From: Josh Poimboeuf To: Andrew Cooper Cc: LKML , x86@kernel.org, Borislav Petkov , Peter Zijlstra , Babu Moger , David.Kaplan@amd.com, Nikolay Borisov , gregkh@linuxfoundation.org, Thomas Gleixner Subject: Re: [PATCH RFC 4/4] x86/srso: Use CALL-based return thunks to reduce overhead Message-ID: <20230821151636.onk2e6tlhmjg5yz5@treble> References: <20230821112723.3995187-1-andrew.cooper3@citrix.com> <20230821112723.3995187-5-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20230821112723.3995187-5-andrew.cooper3@citrix.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 21, 2023 at 12:27:23PM +0100, Andrew Cooper wrote: > The SRSO safety depends on having a CALL to an {ADD,LEA}/RET sequence which > has been made safe in the BTB. Specifically, there needs to be no pertubance > to the RAS between a correctly predicted CALL and the subsequent RET. > > Use the new infrastructure to CALL to a return thunk. Remove > srso_fam1?_safe_ret() symbols and point srso_fam1?_return_thunk(). > > This removes one taken branch from every function return, which will reduce > the overhead of the mitigation. It also removes one of three moving pieces > from the SRSO mess. So, the address of whatever instruction comes after the 'CALL srso_*_return_thunk' is added to the RSB/RAS, and that might be speculated to when the thunk returns. Is that a concern? > Signed-off-by: Andrew Cooper > --- > CC: x86@kernel.org > CC: linux-kernel@vger.kernel.org > CC: Borislav Petkov > CC: Peter Zijlstra > CC: Josh Poimboeuf > CC: Babu Moger > CC: David.Kaplan@amd.com > CC: Nikolay Borisov > CC: gregkh@linuxfoundation.org > CC: Thomas Gleixner > > RFC: > > vmlinux.o: warning: objtool: srso_fam17_return_thunk(): can't find starting instruction > > Any objtool whisperers know what's going on, and particularly why > srso_fam19_return_thunk() appears to be happy? > > Also, depends on the resolution of the RFC in the previous patch. I can take a look. -- Josh