Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp3850712imw; Mon, 18 Jul 2022 16:00:14 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vaJkQDXjnYKca9EtA+OHFt39gfJeyxlwmeGQjh4hmKKTL0RD17coqek/miaOuV6B9fiz6G X-Received: by 2002:a17:902:f689:b0:16c:4fb6:e097 with SMTP id l9-20020a170902f68900b0016c4fb6e097mr29850034plg.136.1658185214136; Mon, 18 Jul 2022 16:00:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1658185214; cv=none; d=google.com; s=arc-20160816; b=DnyJSeCnvDnRUC7BR6puo5JxUJo3r7fkTlvThlyftIKYaaltpo2a6fuEhbZombJ60t dFKVMT11AWBdjQSPrc9vKDQoKpEs5kP3ShtgHRhvTgfykN+5McoEOkTVgCZgi8z63mla fHqsRGWC/RqHld3ECnja58xmJOc/pQ0q50O19dfyhDFL/zGVNxHAKYbd9xbNCE31ZjAn iwgnwbGiGduNhQy6gFVMmSvxRQ0CyMIDYjh09ZF/Zc76zXrK99oeq5sDmD4elOPVPZLO fLkbhFoAwbax4uJFKzneBsKmuv5mTNzrqSvHkbuVW4UrcFH2ALK1OZNElAmLDCX2NWMD 7+Mw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=DFiFHivs8Lja1WLmWY06OuHT01tol+Zj00tV0o3LV8U=; b=xKt5rLx1+5VUpZLOpO/vjAW6DBIcIrj1p0iUn7pNqEl+5SntwQ7nAttyRwpZetnVI+ x61eva57gZ4qmNn6zgdEFCI8rgyVy+aTlO4tZfS0CjmGvmdTL54c0lBlwU9twVz9dfH/ tcGspViqBLDnKfwdEUD0Dy/ExWOyT6nPBaNnZTFAWI3wvE/dqmMNunjbVHDxuobN6aEa rD5mkZFsUUwD13dH9J3k6bKFWo+X3TlWwL24nNnNkcqIcDLdiRmfN4QA0lR0fy4yEHSl 4LSn6nwu8v35TicfCJcQAtsGb5NmUWKh+Q2gK6zwTNYRvYsLAtV4boaVvuENDTvq9FGz plLQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=AhoPVIiI; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id lk4-20020a17090b33c400b001ecfcc0a97dsi25290984pjb.71.2022.07.18.15.59.58; Mon, 18 Jul 2022 16:00:14 -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; dkim=pass header.i=@google.com header.s=20210112 header.b=AhoPVIiI; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236070AbiGRW4J (ORCPT + 99 others); Mon, 18 Jul 2022 18:56:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52274 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233921AbiGRW4I (ORCPT ); Mon, 18 Jul 2022 18:56:08 -0400 Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8FAC2E0D7 for ; Mon, 18 Jul 2022 15:56:06 -0700 (PDT) Received: by mail-yb1-xb2f.google.com with SMTP id 64so23548607ybt.12 for ; Mon, 18 Jul 2022 15:56:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DFiFHivs8Lja1WLmWY06OuHT01tol+Zj00tV0o3LV8U=; b=AhoPVIiIoLF4TMNFR34Ra10DQtCyQ872y3I+ySo+v2Huysy0iVdBO4fkhi4otyg9bo +yYk8NGnSR/QIyC/fjZtV10JPWtJuQIJksprUMnd+zc45E+HNVxBU0cOga46XwXnRW6p eBkEfDEBH/DeFrO7xZLsC8jx6UlZ2uB2w9qug7gk54OoNrDIaGS4F3Dmq3lBzv3UYmeO aX5IW8iWjCyrUv3M4wjopwZpeSzZSdn7dT22QywPaaDNfKv9fzmAOsO1vtlLQIjm+mrE cDehz8k0/NAL1UqPN17M35wEZOS7q6V5rl0GUZKkzSk2vpdm89bK9xsYNSbX8NrjPVnU 54tQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DFiFHivs8Lja1WLmWY06OuHT01tol+Zj00tV0o3LV8U=; b=QBa1jA0uw7pgwOQ7ISwPmnm/7IM69bYNtmgIxrzmBNIJUBJ8ibJx+8GJfx69u0XLVd 2V871kn5gq+XZRCLWBX0vF7UxTcnbGXiQ+VoiWsWjiZf+f1U7hFkLpwhKHPW3GUBFAxF v84JLV8Ykuzgq6QDo0YviZWmswI8m4ZI7hXWzaCJEC6kGvuLPDgiRUYBXDBeTzaGLKlz lriNU/dn2x9MQFFZBtLvwoVC3SxVUaVHrKHCTBnDZqAqMRy7Ra9AcBbEmOgRNSIRxYQH cgcduei21OkKB/5XSvuKlpOJndocrOf7n+xo3i7VYnJwOMvUmFV07aW4Hj0VSUG/JLyv p1kg== X-Gm-Message-State: AJIora97wKV70mf2qIftrH7o63JBs/YmssLur06cvQB7A8ieinG5rBMr YnUjZ1PKkLdyb1G3YWT+OpfxWBcaiKGdzi6Hn+uc5g== X-Received: by 2002:a05:6902:124d:b0:66d:5ce6:5924 with SMTP id t13-20020a056902124d00b0066d5ce65924mr30346821ybu.320.1658184965712; Mon, 18 Jul 2022 15:56:05 -0700 (PDT) MIME-Version: 1.0 References: <20220716230344.239749011@linutronix.de> <87wncauslw.ffs@tglx> <87tu7euska.ffs@tglx> <87o7xmup5t.ffs@tglx> <87lesqukm5.ffs@tglx> <2f7f899cb75b79b08b0662ff4d2cb877@overdrivepizza.com> In-Reply-To: <2f7f899cb75b79b08b0662ff4d2cb877@overdrivepizza.com> From: Sami Tolvanen Date: Mon, 18 Jul 2022 15:55:29 -0700 Message-ID: Subject: Re: [patch 00/38] x86/retbleed: Call depth tracking mitigation To: Joao Moreira Cc: Thomas Gleixner , Peter Zijlstra , "Torvalds, Linus" , 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 Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL 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 On Mon, Jul 18, 2022 at 3:47 PM Joao Moreira wrote: > Thus the hash will be 6 bytes before the function entry point. Then we > can get the compiler to emit a padding area before the __cfi_\func > snippet and, during boot, if the CPU needs the call depth tracking > mitigation, we: > - move the __cfi_func into the padding area > - patch the call depth tracking snippet ahead of it (overwriting the old > __cfi_\func:) > - fix the cmpl offset in the caller > > func_whatever: > ... > cmpl $0x\hash, -FIXED_OFFSET(%rax) > je 1f > ud2 > 1: > call *%rax > ... The problem with this is that the cmpl instruction contains the full type hash, which means that any instruction that's FIXED_OFFSET from the cmpl is a valid indirect call target as far as KCFI is concerned. -6 was chosen specifically to make the ud2 the only possible target. Sami