From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 18829EC5 for ; Mon, 16 May 2022 11:45:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=MjT6Lh2fWnIRqcyu9+fU8ljp/f9ciDwE1jZdLagfUro=; b=DIyr6/C/OlBvy/oySvPFldi/21 rOpTYtej3bizi+u7/K16YCrPzqB2hqe+RX9d6p7xbu3sp6GMJhzpq0v/JLqUod/xTtmlAv35QLUEj /wInc/XEfEZq+E70DWAPyASnQmaV5dqmdCGSjZ2qhGSgY/85J8I/gN1+hIvaHSDg5ST8in3v8iDwj jcMnpAa6C+r98QB7QvCCIFBAR5G2Vs/dsvb5tzsnEPYZosIs6GhIodV1v/BQ8U2audosn96Y/k164 gWZ+2yLr1TKifY4KPI4zoecKJmS+RdcxtOvj2eV1CHP8EH1qgoKQ3Wn8fSSV/h9Can4XPg/um6NB+ cXl0RWjA==; 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 1nqZA8-000w7T-0G; Mon, 16 May 2022 11:45:20 +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 (4096 bits) server-digest SHA256) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 53103300268; Mon, 16 May 2022 13:45:17 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 12EC620225E64; Mon, 16 May 2022 13:45:17 +0200 (CEST) Date: Mon, 16 May 2022 13:45:17 +0200 From: Peter Zijlstra To: Sami Tolvanen Cc: linux-kernel@vger.kernel.org, Kees Cook , Josh Poimboeuf , x86@kernel.org, Catalin Marinas , Will Deacon , Mark Rutland , Nathan Chancellor , Nick Desaulniers , Joao Moreira , Sedat Dilek , Steven Rostedt , linux-hardening@vger.kernel.org, linux-arm-kernel@lists.infradead.org, llvm@lists.linux.dev Subject: Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG Message-ID: References: <20220513202159.1550547-1-samitolvanen@google.com> <20220513202159.1550547-21-samitolvanen@google.com> Precedence: bulk X-Mailing-List: llvm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Mon, May 16, 2022 at 11:54:33AM +0200, Peter Zijlstra wrote: > On Fri, May 13, 2022 at 01:21:58PM -0700, Sami Tolvanen wrote: > > With CONFIG_CFI_CLANG, the compiler injects a type preamble > > immediately before each function and a check to validate the target > > function type before indirect calls: > > > > ; type preamble > > __cfi_function: > > int3 > > int3 > > mov , %eax > > int3 > > int3 > > function: > > ... > > When I enable CFI_CLANG and X86_KERNEL_IBT I get: > > 0000000000000c80 <__cfi_io_schedule_timeout>: > c80: cc int3 > c81: cc int3 > c82: b8 b5 b1 39 b3 mov $0xb339b1b5,%eax > c87: cc int3 > c88: cc int3 > > 0000000000000c89 : > c89: f3 0f 1e fa endbr64 > > > That seems unfortunate. Would it be possible to get an additional > compiler option to suppress the endbr for all symbols that get a __cfi_ > preaamble? > > Also, perhaps s/CFI_CLANG/KERNEL_CFI/ or somesuch, so that GCC might > also implement this same scheme (in time)? > > > ; indirect call check > > cmpl    , -6(%r11) > > je .Ltmp1 > > ud2 > > .Ltmp1: > > call __x86_indirect_thunk_r11 > > The first one I try and find looks like: > > 26: 41 81 7b fa a6 96 9e 38 cmpl $0x389e96a6,-0x6(%r11) > 2e: 74 02 je 32 <__traceiter_sched_kthread_stop+0x29> > 30: 0f 0b ud2 > 32: 4c 89 f6 mov %r14,%rsi > 35: e8 00 00 00 00 call 3a <__traceiter_sched_kthread_stop+0x31> 36: R_X86_64_PLT32 __x86_indirect_thunk_r11-0x4 > > This must not be. If I'm to rewrite that lot to: > > movl $\hash, %r10d > sub $9, %r11 > call *%r11 > .nop 4 > > Then there must not be spurious instruction in between the ud2 and the > indirect call/retpoline thing. Hmmm.. when I replace it with: movl $\hash, %r10d sub $9, %r11 .nops 2 That would work, that has the added benefit of nicely co-existing with the current retpoline patching. The only remaining problem is how to find this; the .retpoline_sites is fairly concenient, but if the compiler can put arbitrary amounts of code in between this is going to be somewhat tedious. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 19616C433EF for ; Mon, 16 May 2022 11:46:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=WbvheTUVSNt2/X2ZS6u1tFQsPaud++h4wESG7bd31Fw=; b=bjfVLlC8tM1bHH jC1H3UVlcaqORtsO5J3PV4HiDrqA6WytoGQx5PpDz1wJDJyFeVrptic2wg+UblcZ9sFiD1bxDlCSs RsDEWNU8yRk8/mMIAa2ga5L9ODRKzDkvsF2z+9wZP1U/Kl05lg3VQWJE2tr7WHAmjhWcAke2BFWgJ q3EuH1ES8pe+ahujj2jXjVqYd3vuu7RvljTSynhRaJNU7B3ITQI5+e5iIyvngL7M9YqEgh22FjDFX /t04OBrYaa55LYHas/lx0oNa6G8uQPaALuF5Cn0EZOmSMkm05pWtmufojjoxVkYq+Q7EYLL40Inmq vbYX8H9j4o0k9RfCBYbQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nqZAH-007MjW-B0; Mon, 16 May 2022 11:45:29 +0000 Received: from desiato.infradead.org ([2001:8b0:10b:1:d65d:64ff:fe57:4e05]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nqZAF-007Mhx-AM for linux-arm-kernel@bombadil.infradead.org; Mon, 16 May 2022 11:45:27 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=MjT6Lh2fWnIRqcyu9+fU8ljp/f9ciDwE1jZdLagfUro=; b=DIyr6/C/OlBvy/oySvPFldi/21 rOpTYtej3bizi+u7/K16YCrPzqB2hqe+RX9d6p7xbu3sp6GMJhzpq0v/JLqUod/xTtmlAv35QLUEj /wInc/XEfEZq+E70DWAPyASnQmaV5dqmdCGSjZ2qhGSgY/85J8I/gN1+hIvaHSDg5ST8in3v8iDwj jcMnpAa6C+r98QB7QvCCIFBAR5G2Vs/dsvb5tzsnEPYZosIs6GhIodV1v/BQ8U2audosn96Y/k164 gWZ+2yLr1TKifY4KPI4zoecKJmS+RdcxtOvj2eV1CHP8EH1qgoKQ3Wn8fSSV/h9Can4XPg/um6NB+ cXl0RWjA==; 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 1nqZA8-000w7T-0G; Mon, 16 May 2022 11:45:20 +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 (4096 bits) server-digest SHA256) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 53103300268; Mon, 16 May 2022 13:45:17 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 12EC620225E64; Mon, 16 May 2022 13:45:17 +0200 (CEST) Date: Mon, 16 May 2022 13:45:17 +0200 From: Peter Zijlstra To: Sami Tolvanen Cc: linux-kernel@vger.kernel.org, Kees Cook , Josh Poimboeuf , x86@kernel.org, Catalin Marinas , Will Deacon , Mark Rutland , Nathan Chancellor , Nick Desaulniers , Joao Moreira , Sedat Dilek , Steven Rostedt , linux-hardening@vger.kernel.org, linux-arm-kernel@lists.infradead.org, llvm@lists.linux.dev Subject: Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG Message-ID: References: <20220513202159.1550547-1-samitolvanen@google.com> <20220513202159.1550547-21-samitolvanen@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, May 16, 2022 at 11:54:33AM +0200, Peter Zijlstra wrote: > On Fri, May 13, 2022 at 01:21:58PM -0700, Sami Tolvanen wrote: > > With CONFIG_CFI_CLANG, the compiler injects a type preamble > > immediately before each function and a check to validate the target > > function type before indirect calls: > > = > > ; type preamble > > __cfi_function: > > int3 > > int3 > > mov , %eax > > int3 > > int3 > > function: > > ... > = > When I enable CFI_CLANG and X86_KERNEL_IBT I get: > = > 0000000000000c80 <__cfi_io_schedule_timeout>: > c80: cc int3 > c81: cc int3 > c82: b8 b5 b1 39 b3 mov $0xb339b1b5,%eax > c87: cc int3 > c88: cc int3 > = > 0000000000000c89 : > c89: f3 0f 1e fa endbr64 > = > = > That seems unfortunate. Would it be possible to get an additional > compiler option to suppress the endbr for all symbols that get a __cfi_ > preaamble? > = > Also, perhaps s/CFI_CLANG/KERNEL_CFI/ or somesuch, so that GCC might > also implement this same scheme (in time)? > = > > ; indirect call check > > cmpl=A0 =A0 , -6(%r11) > > je .Ltmp1 > > ud2 > > .Ltmp1: > > call __x86_indirect_thunk_r11 > = > The first one I try and find looks like: > = > 26: 41 81 7b fa a6 96 9e 38 cmpl $0x389e96a6,-0x6(%r11) > 2e: 74 02 je 32 <__traceiter_sched_kthread_st= op+0x29> > 30: 0f 0b ud2 > 32: 4c 89 f6 mov %r14,%rsi > 35: e8 00 00 00 00 call 3a <__traceiter_sched_kthread_st= op+0x31> 36: R_X86_64_PLT32 __x86_indirect_thunk_r11-0x4 > = > This must not be. If I'm to rewrite that lot to: > = > movl $\hash, %r10d > sub $9, %r11 > call *%r11 > .nop 4 > = > Then there must not be spurious instruction in between the ud2 and the > indirect call/retpoline thing. Hmmm.. when I replace it with: movl $\hash, %r10d sub $9, %r11 .nops 2 That would work, that has the added benefit of nicely co-existing with the current retpoline patching. The only remaining problem is how to find this; the .retpoline_sites is fairly concenient, but if the compiler can put arbitrary amounts of code in between this is going to be somewhat tedious. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel