Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp1384434pxb; Sat, 30 Oct 2021 12:09:30 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw8tJYl9KvcjSv6CzADOW9NLrPvRKNvu1+s2LKpWC5cNU/Q5I1oJ7thzsIcr7/6U1ptIU9T X-Received: by 2002:a92:c846:: with SMTP id b6mr5280990ilq.255.1635620970773; Sat, 30 Oct 2021 12:09:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635620970; cv=none; d=google.com; s=arc-20160816; b=eIqkyo50cqlp9lKWBWC4FQ0UBATJtfraguVGL58QON47WSEUUaj3G9DccXGthBDt6k DdO/GfrQQLuekBZRNM8kr15GyCfZJoYlv/R9ut5+17671YjhU30VJ1Z68Td1zg7rLwjI 9oOPivQdlFL2sxWAxAowc3htu9ycgvcy5JDb/X0/jzcpI42T8KkJWZSvcxLEitdv7+fQ vLwtJxSQKSIrLkiEXeUNySlb8FJzPvln4WM7gW5xNQj4eLEMFFGAvsfIOXQYlI/yniuW O29ejE0yPcAIjXmKFNXnv0iZaACvNg6eGi/nLlZEaOGfbHz8jXtrK9ucH0rjdo6N1qyJ jZcg== 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=CD2RlII1WVp7MOTRa0mnhnUU9/NjsujY0FdiDhkiMRE=; b=pFHCv4Dgy+PZ4ItUlKrScuPFRAX9GVCCE2C0gOicRlxMMFZaX/AN/PaD7PBSwDuE6j dnJ9lOVC5FMx4py9VCm2n+Id9134zdwgaz//UomZ2enQKBQ6UnHU6ThjHf6HA0JI4dwJ jSAreMAQbnmZNRukE6nwMXGPI89XEEMogPzIS5Mmxa7ROS5MLshayFztJMQTB9H3MQhQ ClIzRYAly3NKpro46lbBn9aRJB60ECypO5u62z8U0kQ9MNTkGOZTHfO+p9Uq3IDnHd1u SjFr8mqGtIMH2786ZoGZKZ4fNlNmCBKCvvnlbxb1YvNjsZrv4ObVYIuRZAknGG63VRqk yLnw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=qCPIOU9G; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g9si14413821iov.42.2021.10.30.12.09.19; Sat, 30 Oct 2021 12:09:30 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=qCPIOU9G; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S229658AbhJ3TKj (ORCPT + 99 others); Sat, 30 Oct 2021 15:10:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55002 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229641AbhJ3TKi (ORCPT ); Sat, 30 Oct 2021 15:10:38 -0400 Received: from mail-yb1-xb35.google.com (mail-yb1-xb35.google.com [IPv6:2607:f8b0:4864:20::b35]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2CC6AC061570 for ; Sat, 30 Oct 2021 12:08:08 -0700 (PDT) Received: by mail-yb1-xb35.google.com with SMTP id d10so22412126ybe.3 for ; Sat, 30 Oct 2021 12:08:08 -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=CD2RlII1WVp7MOTRa0mnhnUU9/NjsujY0FdiDhkiMRE=; b=qCPIOU9GxvfXvw4Mc7xnO0zT6yYKxzP06wsu9k2jfBIXScVg+Gxs6fIBAcHlQN0W2I rpD5DKkZgZ5p1g3scnrPOtX14ePFwPafNmX5Un0wQ5Y1+3438LQOYwKRNoP7HapoEJrf NnK7FOZGPnXclhkL6Hu2phBIrp9Ar6/+nlPhZjJH3wk1r3bITWiJbnWzInqmCadSY6dw qfc3L3PtHfX1a66ZKnAueG5cDhofYtawaZxeUqfzCg3G0q/UmBbUVuSJPTkI0ZpmRcHb Z8w0d9HY5hWtFj4zgGOkTCI9wUxi1vp9lf4jnLL+pV/HApMRaFYtdf6oNvUjvz17+uvL 5p0Q== 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=CD2RlII1WVp7MOTRa0mnhnUU9/NjsujY0FdiDhkiMRE=; b=0y8bXY0yqUmQGXwzO28dAsRB79OsyaWoMt3L5fdvTbRiSyzS+E7kXQhj8zd+Y7wW+p 62eOHEIrwvDYooRAC5it45uvzGvNPqsY9d+cm91v/lx+23WzKCtTRLf+ZR+jKrFJZFi5 QyjmpQyVzjdc0bFaY6WdAIpm22EnoDV7B5DDlnxWWj5idB6iOaj7VF7GGAvzHVFPWwFv snuvdaWFCEbJYivxxRGirVgb6LJrA9Jy1rLEE5S0ciFSyclS/6/pMbcNtjC3CrD/Fay8 7FfYiGfsKbvi8Xl6lX3igqiQUfr8jQKhOaf82n4uQv7VUTYTGSSxl9BR+DHGI/RhC0zm OB3w== X-Gm-Message-State: AOAM5310xRxqWcTPV1CrJpiji0OzNHEVnJIg1c5aRY/brM6qqJ1j2Fca SNsjhyj8EaqeHrv1eDbn4avFxD5ywCg5ptTi9ykfhQ== X-Received: by 2002:a25:2d66:: with SMTP id s38mr1787157ybe.527.1635620886905; Sat, 30 Oct 2021 12:08:06 -0700 (PDT) MIME-Version: 1.0 References: <20211013181658.1020262-1-samitolvanen@google.com> <20211026201622.GG174703@worktop.programming.kicks-ass.net> <20211027120515.GC54628@C02TD0UTHF1T.local> <20211027124852.GK174703@worktop.programming.kicks-ass.net> <20211029200324.GR174703@worktop.programming.kicks-ass.net> In-Reply-To: <20211029200324.GR174703@worktop.programming.kicks-ass.net> From: Sami Tolvanen Date: Sat, 30 Oct 2021 12:07:56 -0700 Message-ID: Subject: Re: [PATCH v5 00/15] x86: Add support for Clang CFI To: Peter Zijlstra Cc: Ard Biesheuvel , Mark Rutland , X86 ML , Kees Cook , Josh Poimboeuf , Nathan Chancellor , Nick Desaulniers , Sedat Dilek , Steven Rostedt , linux-hardening@vger.kernel.org, Linux Kernel Mailing List , llvm@lists.linux.dev Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 29, 2021 at 1:04 PM Peter Zijlstra wrote: > > On Wed, Oct 27, 2021 at 08:50:17AM -0700, Sami Tolvanen wrote: > > On Wed, Oct 27, 2021 at 7:18 AM Ard Biesheuvel wrote: > > > > > /* > > > > * Turns a Clang CFI jump-table entry into an actual function pointer. > > > > * These jump-table entries are simply jmp.d32 instruction with their > > > > * relative offset pointing to the actual function, therefore decode the > > > > * instruction to find the real function. > > > > */ > > > > static __always_inline void *nocfi_ptr(void *func) > > > > { > > > > union text_poke_insn insn = *(union text_poke_insn *)func; > > > > > > > > return func + sizeof(insn) + insn.disp; > > > > } > > > > > > > > But really, that wants to be a compiler intrinsic. > > > > > > Agreed. We could easily do something similar on arm64, but I'd prefer > > > to avoid that too. > > > > I'll see what we can do. Note that the compiler built-in we previously > > discussed would have semantics similar to function_nocfi(). It would > > return the raw function address from a symbol name, but it wouldn't > > decode the address from an arbitrary pointer, so this would require > > something different. > > So I had a bit of a peek at what clang generates: > > 3fa4: 48 c7 c7 00 00 00 00 mov $0x0,%rdi 3fa7: R_X86_64_32S __SCK__x86_pmu_handle_irq > 3fab: 48 c7 c6 00 00 00 00 mov $0x0,%rsi 3fae: R_X86_64_32S __SCT__x86_pmu_handle_irq.cfi_jt > 3fb2: e8 00 00 00 00 call 3fb7 3fb3: R_X86_64_PLT32 __static_call_update-0x4 > > So this then gives the trampoline jump table entry to > __static_call_update(), with the result that it will rewrite the > jump-table entry, not the trampoline! > > Now it so happens that the trampoline looks *exactly* like the > jump-table entry (one jmp.d32 instruction), so in that regards it'll > again 'work'. Ugh, good catch! > But this is all really, as in *really*, wrong. And I'm really sad I'm > the one to have to discover this, even though I've mentioned > static_call()s being tricky in previous reviews. My bad, I didn't realize Clang does this with a typeof(func) declaration. I'll make sure we have a reasonable fix for this before the next version. Sami