Received: by 2002:ac0:da4c:0:0:0:0:0 with SMTP id a12csp919255imi; Thu, 21 Jul 2022 13:36:41 -0700 (PDT) X-Google-Smtp-Source: AGRyM1tC6la038LwY7Lt9O8gAyYBLTnOY9l69QCNxCqy8O5f3jUHw5LVYhNRu1Xwpi3X60N5d/yy X-Received: by 2002:a17:90b:4a47:b0:1f2:213b:f6dd with SMTP id lb7-20020a17090b4a4700b001f2213bf6ddmr10193038pjb.177.1658435801369; Thu, 21 Jul 2022 13:36:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1658435801; cv=none; d=google.com; s=arc-20160816; b=O9RvUIy+YFS41eiL1KtU91tOQoSUjUGDSpIYhOdlvKBEZU6hHYTREhJzpfyjfrVamQ wBlWduoERvztqwOY56n5NOEz5FG4vfa24SSn01Z7W3DRtzSDGHPhL131/ZoCKaPO0AER 3Tsm0cTErBjd9+w+snEdmBzPUvKizJHzey/mDMi0PriwxLi5qHQdp0sCS0fLO2/5UD/+ oe+/qpXSP7+RCMt8w7Aul7n9OeclhTqhxQHIvfW/S6BGdiqOYNCidpBR2/ONSC74wpAu 7wLFUSwnscaC+sg+J62dq9Yim6zLbXYcZSymffaivrpxjkhca6nkUIig0NIGXccxS89G 1ziw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:message-id:references :in-reply-to:subject:cc:to:from:date:mime-version; bh=ae91sEBA4Yx0Vgbh79cbf6DMS3fLbcly/Uo8T9QAZqk=; b=UvwEot2lyeGebdtKXwBmEqdKLla072d3VzU6C3+BQ8bc9R2Opbi6yJfecwYllG1KUT XIRt1Nrc98fHlJHhxWoVRuc4+7ohK1In8cffySmtice3u2s9KUq62y0qy/U+Fh3MFE4H NvtvreonYHfAsMFHQNNGaoJHRiBnnsTe0wVFqxpLcTMtwrqvtV34T+ccc1N83+FfugIt ollg+NRENG+f0P1q0mublWGXM0Tts3+oc7vbkCT3n7o+4zhiGfMFGdD9VITaQT7VBP37 IciTCPSM3k/BuFNbZ7jsHyhqprGDKJ7LM08fQDGMEA8zFo2tiEHdcKGO4yPHeoDv6B1o RBrA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id u26-20020a056a00099a00b0052aaf7fecd0si4708610pfg.18.2022.07.21.13.36.26; Thu, 21 Jul 2022 13:36:41 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233181AbiGUUWY (ORCPT + 99 others); Thu, 21 Jul 2022 16:22:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53470 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229547AbiGUUWX (ORCPT ); Thu, 21 Jul 2022 16:22:23 -0400 Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [217.70.183.198]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6468B87368 for ; Thu, 21 Jul 2022 13:22:19 -0700 (PDT) Received: (Authenticated sender: joao@overdrivepizza.com) by mail.gandi.net (Postfix) with ESMTPA id ADCA8C0002; Thu, 21 Jul 2022 20:22:12 +0000 (UTC) MIME-Version: 1.0 Date: Thu, 21 Jul 2022 13:22:12 -0700 From: Joao Moreira To: Linus Torvalds Cc: Peter Zijlstra , Sami Tolvanen , Thomas Gleixner , LKML , the arch/x86 maintainers , Tim Chen , Josh Poimboeuf , "Cooper, Andrew" , Pawan Gupta , Johannes Wikner , Alyssa Milburn , Jann Horn , "H.J. Lu" , "Moreira, Joao" , "Nuzman, Joseph" , Steven Rostedt , "Gross, Jurgen" , Masami Hiramatsu , Alexei Starovoitov , Daniel Borkmann , Peter Collingbourne , Kees Cook Subject: Re: [patch 00/38] x86/retbleed: Call depth tracking mitigation In-Reply-To: References: Message-ID: <2ba33fe385b7043830e1a8d428047e53@overdrivepizza.com> X-Sender: joao@overdrivepizza.com Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > Ok. I don't know the context, but I was thinking along the lines of > the same hash value perhaps being used multiple times because it has > the same function type. Then using the "addl" trick means that the > hash value in %r10 will be changing and cannot be re-used. Fwiiw, even if %r10 value was not being destroyed by the "addl", the call right after the check implies that you cannot trust the contents of %r10 anymore (it may have been messed up within the called function).