Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp914188pxb; Sat, 30 Oct 2021 01:20:21 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyV7bceQRddzB6NTryFrIg17Y7QzcHmBJQ6/viTN+p7BpJx5i+uLRuwlEg57HdJXWCNWEUK X-Received: by 2002:a05:6e02:df1:: with SMTP id m17mr10686984ilj.125.1635582021108; Sat, 30 Oct 2021 01:20:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635582021; cv=none; d=google.com; s=arc-20160816; b=QryS+SnKZ0hXvlAIzck5WwVyVfRNnSI27UhxRPscRGRsemKKx++5QTef7Bwo5BrrCP RqdtIBFjG/IQ6VeKzZ8I4qsXI5Y0uC4UcEqTnQoElI3qmrPBFq9QmMzvSXTxYY/K9ox7 nOPtmvmqRHohCtSsxU+dhN2h/LAENVvFQUfkY7JaEznaziQ2rDDqMIZgYzXkGyF+wau6 KLbw/z6DnpYCwbGp8qlwBe1loKAqQH2hNLv1LFATvWFT7KZOqEnJ0pEPVTG9ppL9fzN+ /9ApcP1wmTwt26xQWfeliEQTJCXdEqhQETqRAakPgDh3jh8RMMMPRA0RbDYS6q6n5Dxu EyGQ== 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=OsAU1X/ym1O2wGNMWXfa64U4N11rGKkMYQvMe3I0gUI=; b=gZZNJ1ff0K4JKQHxUaby9QJBELwQXD/cUqlbEyG8OPSo1RhrHoKTSRB+WIiztMVyRG SwviZIDexq4WXzii5qe4Iyl4m7F6D65I/sswBiuB7UlwTzwhG9yN9StJo8VIGx9/0iyM yoGta+i4Mc5MBT0CirQbLTlRyAv039VyiDAswW8h5fO4EiArwQqvf42BahqskQXDMoYd mhBmDZDHrxFCm6A3cfOVn+R7YU1FnHXBm7oxnh4UK5ILXEaczgpiwbcYajfNncWX6aiv Do299thzVA++xpVAyYx4vw6ku1qYXSgCnNKZVuPMqXhNnS4yl66FkqcIpdYeC3PyfmUg aV4Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=Znk8T7Hk; 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 p17si13561902iov.108.2021.10.30.01.20.07; Sat, 30 Oct 2021 01:20:21 -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=casper.20170209 header.b=Znk8T7Hk; 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 S231695AbhJ3IVf (ORCPT + 99 others); Sat, 30 Oct 2021 04:21:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56156 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229546AbhJ3IVe (ORCPT ); Sat, 30 Oct 2021 04:21:34 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B0628C061570; Sat, 30 Oct 2021 01:19:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; 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=OsAU1X/ym1O2wGNMWXfa64U4N11rGKkMYQvMe3I0gUI=; b=Znk8T7HkbjMxUm+OAnv03Ub4Fs uevcDyelW6+m+1hwPFX+kz/FfOEvcvO/R1s6hxVQr6hbHCyinV2PKAIOphy2XUuGCGYCpBt04olIN Mso9Ny7kq9tx6YRKpydNqUIz/nZyPu/TmdzWyXJmc2eveFDhQ/A/8K06JknYDtlrLcSQf35la5uVq vo6ndIaYmMSzngZxwqKTb4PZPtcN6A5F2Zupxc2jDjn5urpfosjhlmd1J7ctewQBBTR1UFbZ076BY ysTw/pnYu194JxL5IImt8C1uN6BR2MRWMTxtWFYjV1uRrNcXifNZv594C3SlGHNHEaPxq+QRyIhAR DTNWbjLA==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=worktop.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1mgjXT-002JF8-L4; Sat, 30 Oct 2021 08:16:41 +0000 Received: by worktop.programming.kicks-ass.net (Postfix, from userid 1000) id 10A1B986244; Sat, 30 Oct 2021 10:16:31 +0200 (CEST) Date: Sat, 30 Oct 2021 10:16:31 +0200 From: Peter Zijlstra To: Sami Tolvanen 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, joao@overdrivepizza.com Subject: Re: [PATCH] static_call,x86: Robustify trampoline patching Message-ID: <20211030081631.GF174730@worktop.programming.kicks-ass.net> References: <20211027120515.GC54628@C02TD0UTHF1T.local> <20211027124852.GK174703@worktop.programming.kicks-ass.net> <20211029200324.GR174703@worktop.programming.kicks-ass.net> <20211030074758.GT174703@worktop.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211030074758.GT174703@worktop.programming.kicks-ass.net> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Oct 30, 2021 at 09:47:58AM +0200, Peter Zijlstra wrote: > On Fri, Oct 29, 2021 at 10:03:24PM +0200, Peter Zijlstra wrote: > > > 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'. > > > > 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. > > The below makes the clang-cfi build properly sick: > > [ 0.000000] trampoline signature fail > [ 0.000000] ------------[ cut here ]------------ > [ 0.000000] kernel BUG at arch/x86/kernel/static_call.c:65! So fundamentally I think the whole notion that the address of a function is something different than 'the address of that function' is an *utter* fail. So things like FineIBT use a scheme where they pass a hash value along with the indirect call, which is veryfied at the other end. Can't we adjust it like: foo.cfi: endbr xorl $0xdeadbeef, %r10d jz foo ud2 nop # make it an even 16 bytes foo: # actual function text Then have the address of foo, be the address of foo, like any normal sane person would expect. Have direct calls to foo, go to foo, again, as expected. When doing an indirect call (to r11, as clang does), then, and only then, do: movl $0xdeadbeef, %r10d subq $0x10, %r11 call *%r11 # if the r11 lives, add: addq $0x10, %r11 Then only when caller and callee agree 0xdeadbeef is the password, does the indirect call go through. Why isn't this a suitable CFI scheme even without IBT?