Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp884906pxb; Wed, 27 Oct 2021 14:27:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwZIbzI4Xai+/EQJGc3CeSi+Z6l9NJAZ9/Y4eiwOba187jpvagR4bmSSxf9m6XcjjiDnYtl X-Received: by 2002:a50:e14a:: with SMTP id i10mr454200edl.73.1635370037701; Wed, 27 Oct 2021 14:27:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635370037; cv=none; d=google.com; s=arc-20160816; b=yaSOtvhlM2LccM5l5pleuuCPo4LdYC+Lg2z+8G7yJEhg+tUAJuReC3bu2qKAjppFZW FA7Y1JfAjSr3CRNMI0eZv5hspQLkwLTaE1JR70Gcc9RpxcUhtcC2tZzRr5dfY4Kravd6 ya+WH1Q2g+aRhaOE70R9CNKMxdLbm2amlErbrFwyjYecjjVQv9BvB2lC5BWMFoAaoIP1 Lp14MyMeTRxOx6mPVfQ0ycPGpqDNUiW6J//D0j+IYl+Lm1dPNLdXWrjjwsH6mC+oUKL4 ox0Px6e3UmLHzu9zI+mFhch9vBDybqsvwgr2SAYIqEQOJZRohpQ0b4ce8teX42+0PSlR niIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=rZFyHeRVZKV32ARO4cmxe/axEb+Rr/x9yD53+sl/OlY=; b=zvdBVfzCASqpe86JS2ErPLj3P1KStk99a97y9WJxSB6T+1UtsbU9th439QZIVQvoNe OYaCjqva9VJGOgECpHaw1uMPTPUDbpQZm9f9on89U77+ZC2Sm0YuTWM5jZahb9jQmMCE S0V0dPmXa8/vUSbKP3d+7IS/s7SdiKA+aXBXau80W2JHp8KZVfx9EnmRg004FRB1yMIT LrjSsTML9mvGeLTZZuHEb1VWhFxwzIO7xnz8Gv+Uwu1qujFwA711vY0JPPRqOzqVd1zY Cz1df3ghApxt3ia4BFFeZPzSe8nZH7EsiNwwkoW8fBG1oQAvasF6JSfzKfPpv4oO+apY yFaQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=desiato.20200630 header.b=phKT767j; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dr8si1737754ejc.481.2021.10.27.14.26.53; Wed, 27 Oct 2021 14:27:17 -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=@infradead.org header.s=desiato.20200630 header.b=phKT767j; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242368AbhJ0OGW (ORCPT + 97 others); Wed, 27 Oct 2021 10:06:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37980 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237581AbhJ0OGT (ORCPT ); Wed, 27 Oct 2021 10:06:19 -0400 Received: from desiato.infradead.org (desiato.infradead.org [IPv6:2001:8b0:10b:1:d65d:64ff:fe57:4e05]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3FD30C061570; Wed, 27 Oct 2021 07:03:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=rZFyHeRVZKV32ARO4cmxe/axEb+Rr/x9yD53+sl/OlY=; b=phKT767jvGh32MVsAxMl47EP5P wwCM3/H9RzMOVVZA4ft6XzYW0e6WaC0I6Rv4mhVT5fTAgn0yby2N+wb1MTi6OQQr4EfPzwxaBW7ph acuxsIrP+a7pulqN6j2acgdoK7qxYotO7BtbciWoPZ/ZlqTT5XFaQh6oXS7IJbdr5ojYP5udZljfF SgYGwV7Td9B2DehJC62rCILdXkZLJQpPjaxXUt4OC9P2ZCW6U/1uSl05L1M+hak9MUl1rW2D3hEE1 pQN8LydhRrFUCBYsFjfeXd8srrHEKWxF5Ft7rrIsXEELTfdjvI2fN5HCWR4OQiqn1y8dMlvEZsQOI I265IATA==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1mfjWe-00CZ1O-0S; Wed, 27 Oct 2021 14:03:32 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 7CED530018E; Wed, 27 Oct 2021 16:03:30 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 610572C8E6567; Wed, 27 Oct 2021 16:03:30 +0200 (CEST) Date: Wed, 27 Oct 2021 16:03:30 +0200 From: Peter Zijlstra To: Ard Biesheuvel Cc: Mark Rutland , Sami Tolvanen , 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 Subject: Re: [PATCH v5 00/15] x86: Add support for Clang CFI Message-ID: 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> 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 Wed, Oct 27, 2021 at 03:30:11PM +0200, Ard Biesheuvel wrote: > As far as I can tell from playing around with Clang, the stubs can > actually be executed directly, I had just finished reading the clang docs which suggest as much and was about to try what the compiler actually generates. > they just jumps to the actual function. > The compiler simply generates a jump table for each prototype that > appears in the code as the target of an indirect jump, and checks > whether the target appears in the list. > > E.g., the code below > > void foo(void) {} > void bar(int) {} > void baz(int) {} > void (* volatile fn1)(void) = foo; > void (* volatile fn2)(int) = bar; > > int main(int argc, char *argv[]) > { > fn1(); > fn2 = baz; > fn2(-1); > } > > produces > > 0000000000400594 : > 400594: d65f03c0 ret > > 0000000000400598 : > 400598: d65f03c0 ret > > 000000000040059c : > 40059c: d65f03c0 ret Right, so these are the actual functions ^. > 00000000004005a0
: > 4005a0: a9bf7bfd stp x29, x30, [sp, #-16]! > > // First indirect call > 4005a4: b0000088 adrp x8, 411000 <__libc_start_main@GLIBC_2.17> > 4005a8: f9401508 ldr x8, [x8, #40] > 4005ac: 90000009 adrp x9, 400000 <__abi_tag-0x278> > 4005b0: 91182129 add x9, x9, #0x608 > 4005b4: 910003fd mov x29, sp > 4005b8: eb09011f cmp x8, x9 > 4005bc: 54000241 b.ne 400604 // b.any > 4005c0: d63f0100 blr x8 That's impenetrable to me, sorry. > // Assignment of fn2 > 4005c4: 90000009 adrp x9, 400000 <__abi_tag-0x278> > 4005c8: b0000088 adrp x8, 411000 <__libc_start_main@GLIBC_2.17> > 4005cc: 91184129 add x9, x9, #0x610 > 4005d0: f9001909 str x9, [x8, #48] I'm struggling here, x9 points to the branch at 400610, but then what? x8 is in .data somewhere? > // Second indirect call > 4005d4: f9401908 ldr x8, [x8, #48] > 4005d8: 90000009 adrp x9, 400000 <__abi_tag-0x278> > 4005dc: 91183129 add x9, x9, #0x60c > 4005e0: cb090109 sub x9, x8, x9 > 4005e4: 93c90929 ror x9, x9, #2 > 4005e8: f100053f cmp x9, #0x1 > 4005ec: 540000c8 b.hi 400604 // b.pmore > 4005f0: 12800000 mov w0, #0xffffffff // #-1 > 4005f4: d63f0100 blr x8 > > > 4005f8: 2a1f03e0 mov w0, wzr > 4005fc: a8c17bfd ldp x29, x30, [sp], #16 > 400600: d65f03c0 ret > 400604: d4200020 brk #0x1 > 0000000000400608 <__typeid__ZTSFvvE_global_addr>: > 400608: 17ffffe3 b 400594 > > 000000000040060c <__typeid__ZTSFviE_global_addr>: > 40060c: 17ffffe3 b 400598 > 400610: 17ffffe3 b 40059c And these are the stubs per type. > So it looks like taking the address is fine, although not optimal due > to the additional jump. Right. > We could fudge around that by checking the > opcode at the target of the call, or token paste ".cfi" after the > symbol name in the static_call_update() macro, but it doesn't like > like anything is terminally broken tbh. Agreed, since the jump table entries are actually executable it 'works'. I really don't like that extra jump though, so I think I really do want that nocfi_ptr() thing. And going by: https://clang.llvm.org/docs/ControlFlowIntegrityDesign.html#forward-edge-cfi-for-indirect-function-calls and the above, that might be possible (on x86) with something like: /* * 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.