From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yb1-f177.google.com (mail-yb1-f177.google.com [209.85.219.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 70E7F2C82 for ; Sat, 30 Oct 2021 19:08:08 +0000 (UTC) Received: by mail-yb1-f177.google.com with SMTP id 131so21749489ybc.7 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=IViTh5ZLDNM54SODzGc2TapguoIu+4KQPUsqoxCaI3lxI9zoKWmhygYftrfko5vsZ1 4nofDmTS4ZQtZD3S1YHv3p7FRtRoYAHCAzFbs0OX4wE2rPnQ/QOGzR9pkLuMe/drq9KG Y+ounjHJ99GiMIJFYz4MCfsLqMWYrRFu9JqOEFKwD28G9EOBq5cA2YQgKc99+QzpeSgS xZp3obE+viAXPpcJam7kHGP/Ud5jwiPDzjHMX9vyT1UNes1sJ/kgXld4yb7nbGLGB0rg qRdUBmPKrWouHLxZ2Xa9IKL8JBuZ+ELH1FFCBjEhUlRGfFg4dlQOOu2FLpucQS46CZmj L9EQ== X-Gm-Message-State: AOAM5316QHwydGBvpgROcVdUD0oQqKVHadKzgrwEeFlh8eMbZx+04EQj 3tUs+iiaZnmiTOeSUDfJyRURS5uMpdo/Xu9jVqfe0w== X-Google-Smtp-Source: ABdhPJwCorOhaxiBsJrc7khwbBYNrQ8KwuFb6kQY80aUD8a35DXRG6noMdVjde3oMFCxOrugnlKMPA0CbEY8fahkgVE= X-Received: by 2002:a25:2d66:: with SMTP id s38mr1787157ybe.527.1635620886905; Sat, 30 Oct 2021 12:08:06 -0700 (PDT) Precedence: bulk X-Mailing-List: llvm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: 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" 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