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 C2FE9C433EF for ; Wed, 20 Jul 2022 16:56:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232700AbiGTQ4J (ORCPT ); Wed, 20 Jul 2022 12:56:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55496 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229627AbiGTQ4H (ORCPT ); Wed, 20 Jul 2022 12:56:07 -0400 Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CA90313CF6 for ; Wed, 20 Jul 2022 09:56:06 -0700 (PDT) Received: by mail-pl1-x632.google.com with SMTP id f11so15513064plr.4 for ; Wed, 20 Jul 2022 09:56:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=pXZuRlG5jo3/qyaJ4nhecGIbVjrr3hLyFH8U8e17hLU=; b=G9upKS7bzl/YRVjbw5pWR/u7xJwXXljEL/4mUvSZbTPqJpB1CNlMbfbFxhotpG9PB6 UhokFKRvdLT1NS0HQhAjwJJnH5w4LM8mhBSigMtluxItJbnhoSFyR8pvLn2RwOQ9hy1P FdtjOQlohcHfITpPMcl1rOxQkJ39FzjmAXeZQ1P6tMVMk+ZRcP1WnYSXwx0Lk7qDlhLU BQCN+H5Y+J0phKtPTaE+oFMMpGt2yZUljR1kp4zTbpeG14BApij148lkA24V5+aeNbgS JUWMGCVw+2w7UIeZsTX4dW9q5jfCZMj8qxE+dEeLn4tiTvbFbSVU9BjVT3yIROXYSW0A gBBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=pXZuRlG5jo3/qyaJ4nhecGIbVjrr3hLyFH8U8e17hLU=; b=BfMF2GrciXI9gJrsb6J9xvLC7bAlVxwNyj15xMExG2ul3b9LLZOW+SJmaP50zln4m4 NIlCDIqjGzCfN28B4iKM+i00zcXJEGCyG3cPShiHjnbmJo3GeQSqWJQaJWu78/OsIAYT 0bsmj6eoD5YNxc27M5XfCQICirNP6VtYBe14mM8OpGp7ijpCM9LftapsuXCdV2PxCvOu f5Ap1LPVYZWeHI9f82YS53GPcWzQsR3HMYccMrWpcIEDWATlM1hAT6jIu3ZyO7ed8G6/ Eqz5ZwwDLJqLUkEYEhcdr5maMITIvU+8VPJyw8jFeRPoIBPHxhaWsiYRoqjZAPasOdlU taTQ== X-Gm-Message-State: AJIora/FMPmOwvGheNrn4c/NbFnd/P5DZH8e7ZcKlsF92rI0IKkvqcCT AeNTfod0KGkXe6yLbEGGdOaE9Q== X-Google-Smtp-Source: AGRyM1tOXnK/BzY+tfUIeNIBwJyq3dLKHw5V9IoiyLbeMyS5WUdHNghDuDBN3xgrdtP9VvhJU1qOYA== X-Received: by 2002:a17:90b:1642:b0:1f0:31c1:9e80 with SMTP id il2-20020a17090b164200b001f031c19e80mr6486365pjb.157.1658336165983; Wed, 20 Jul 2022 09:56:05 -0700 (PDT) Received: from google.com ([2620:15c:201:2:1b3a:60da:6fc4:edb3]) by smtp.gmail.com with ESMTPSA id w9-20020a1709026f0900b0016be6a554b5sm14115927plk.233.2022.07.20.09.56.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Jul 2022 09:56:05 -0700 (PDT) Date: Wed, 20 Jul 2022 09:55:59 -0700 From: Sami Tolvanen To: Peter Zijlstra Cc: Thomas Gleixner , Linus Torvalds , LKML , the arch/x86 maintainers , Tim Chen , Josh Poimboeuf , Andrew Cooper , Pawan Gupta , Johannes Wikner , Alyssa Milburn , Jann Horn , "H.J. Lu" , Joao Moreira , Joseph Nuzman , Steven Rostedt , Juergen Gross , Masami Hiramatsu , Alexei Starovoitov , Daniel Borkmann Subject: Re: [patch 00/38] x86/retbleed: Call depth tracking mitigation Message-ID: References: <20220716230344.239749011@linutronix.de> <87wncauslw.ffs@tglx> <87tu7euska.ffs@tglx> <87o7xmup5t.ffs@tglx> 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-kernel@vger.kernel.org On Tue, Jul 19, 2022 at 01:51:14AM +0200, Peter Zijlstra wrote: > So if we assume \func starts with ENDBR, and further assume we've fixed > up every direct jmp/call to land at +4, we can overwrite the ENDBR with > part of the SARQ, that leaves us 6 more byte, placing the immediate at > -10 if I'm not mis-counting. > > Now, the call sites are: > > 41 81 7b fa 78 56 34 12 cmpl $0x12345678, -6(%r11) > 74 02 je 1f > 0f 0b ud2 > e8 00 00 00 00 1: call __x86_indirect_thunk_r11 > > That means the offset of +10 lands in the middle of the CALL > instruction, and since we only have 16 thunks there is a limited number > of byte patterns available there. > > This really isn't as nice as the -6 but might just work well enough, > hmm? I agree, this is probably fine, or at least low enough risk. Did you have thoughts about changing the check instruction sequence to split the hash into multiple instructions and thus avoiding this issue altogether? Sami