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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7BCE6C433F5 for ; Mon, 8 Nov 2021 11:53:50 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 3FC3C6124D for ; Mon, 8 Nov 2021 11:53:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 3FC3C6124D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org 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=3I0f7rZEUNM15l7Q/otKWgdMs11xsPu+ugMtwW7WlUY=; b=3tsRGbmFjhb9IO Hs9NpmTIpRA3kOSQU8NIk02RXDiRU+ShZYSuLl1mfXn28lsBW7ugj9WEaxrpWBP+htAw3PlHzc7tO bTOU2dYBWRNNGdssW1tUbLReigfpAMLMlKi/sVxaD5fDlGYPQAvxMhn/XGSvVfPbMm14okgjQE4A5 WhQFYlT5ndlONGIsFWZxVP4HQZ9R5UywipkFOh2nlAxdlb7ctPYm2pMxb2ryFyC2zBD7pKoprJVgc LVkJ21uGASQzIWcf0Ar1+qf496Wnq8qq7xPBUWNLY2CLlUgC0huoEjZSIo+WpQpi+b6z/fNfPW3JH Gij609HewpF2IDX2qTXQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mk3CX-00GKgF-1S; Mon, 08 Nov 2021 11:52:37 +0000 Received: from casper.infradead.org ([2001:8b0:10b:1236::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mk3CU-00GKfi-NG for linux-arm-kernel@bombadil.infradead.org; Mon, 08 Nov 2021 11:52:34 +0000 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=iGvLUtwPbdRsAfeVJOcAVPj61fXiSzd4nOb67Hfr9sw=; b=F+BJuQ+IrbziNIXT9xJu5L+UqB lraLF91ieb3EqV159cAYbdxPh16m+cadbOWiwl9jcekGoedIewYhnqSHhhBMR7qmFo6cNLMrEiTOH neMlc6vd2JUNmiVxh1iTSzLBHXGzM61RRdXD67CWRqKR3FZe0cFI6bFgVawRKX0mfGI9E1PFMJh2A FQkh+4azXrnUjFKS64DvsnAhK1VH8e2rMEzUhJ9/d7EDudfuZ9U0/a0FfeOZOhFvyNDTwD4qDu9GW guMvF6BRN4pe336JdFGkbJ6qabesfBb0AfOrYp4Ps9LBBs95b486GrznQjoZzSdl8F7ZQQyOJdQgk QpUumMpQ==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1mk3CR-0009SK-Fj; Mon, 08 Nov 2021 11:52: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 8764830030B; Mon, 8 Nov 2021 12:52:31 +0100 (CET) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 5EFD4202A0132; Mon, 8 Nov 2021 12:52:31 +0100 (CET) Date: Mon, 8 Nov 2021 12:52:31 +0100 From: Peter Zijlstra To: Ard Biesheuvel Cc: Linux ARM , Linux Kernel Mailing List , Mark Rutland , Quentin Perret , Catalin Marinas , James Morse , Will Deacon , Frederic Weisbecker , Kees Cook , Sami Tolvanen , Andy Lutomirski , Josh Poimboeuf , Steven Rostedt Subject: Re: [PATCH v6 2/2] arm64: implement support for static call trampolines Message-ID: References: <20211105145917.2828911-1-ardb@kernel.org> <20211105145917.2828911-3-ardb@kernel.org> 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="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Nov 08, 2021 at 12:29:04PM +0100, Ard Biesheuvel wrote: > On Mon, 8 Nov 2021 at 11:23, Peter Zijlstra wrote: > > > +static void *strip_cfi_jt(void *addr) > > > +{ > > > + if (IS_ENABLED(CONFIG_CFI_CLANG)) { > > > + void *p = addr; > > > + u32 insn; > > > + > > > + /* > > > + * Taking the address of a function produces the address of the > > > + * jump table entry when Clang CFI is enabled. Such entries are > > > + * ordinary jump instructions, preceded by a BTI C instruction > > > + * if BTI is enabled for the kernel. > > > + */ > > > + if (IS_ENABLED(CONFIG_ARM64_BTI_KERNEL)) > > > + p += 4; > > > > Perhaps: > > if (aarch64_insn_is_bti(le32_to_cpup(p))) > > That instruction does not exist yet, and it begs the question which > type of BTI instruction we want to detect. Yeah, I actually checked, but I figured the intent was clear enough. I figured all of them? > > p += 4; > > > > Perhapser still, add: > > else > > WARN_ON(IS_ENABLED(CONFIG_ARM64_BTI_KERNEL)); > > > > There's already a WARN() below that will trigger and return the > original address if the entry did not have the expected layout, which > means a direct branch at offset 0x0 or 0x4 depending on whether BTI is > on. > > So I could add a WARN() here as well, but I'd prefer to keep the one > at the bottom, which makes the one here slightly redundant. Sure, that works. The slightly more paranoid me would tell you that the code as is might match something you didn't want it to. Eg. without the extra WARN, you could accidentally match a B instruction without BTI on a BTI kernel build. Or your initial version could even match: RET; B ponies; on a BTI kernel. My point being that since we're not exactly sure what a future compiler will generate for us here, we'd best be maximally paranoid about what we're willing to accept. > > > + > > > + insn = le32_to_cpup(p); > > > + if (aarch64_insn_is_b(insn)) > > > + return p + aarch64_get_branch_offset(insn); > > > + > > > + WARN_ON(1); > > > + } > > > + return addr; > > > +} > > > > Also, can this please have a comment decrying the lack of built-in for > > this? > > Sure. Which ties in with that. Once it's a built-in, we can be sure the compiler knows what it needs to do to undo it's own magic. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel