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 0F5BBC433FE for ; Sat, 22 Oct 2022 14:58:31 +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=KXRsi0+To1G/Hgyt41Pqv+jRv7wr6WegKcfcT807ikw=; b=B5XVn8Z5MmOzKb CmzvYVqbJ1rFOvxE8qxm3SduTgV+ypKmaVDrcQFxJKoqlXeawxfE8VYhV0YxU3ROqSqgB9zxF7Y7V Wv33qyQEt4lBOXAQq9Zg+xFmbLLrBEsFeAqAZnoEWGSY9AdYg0HkZJID39pXOfCXVwIF9PRGHgIUx nS4i4kES1FwbaecTgXBL+A3DQhr9dQR+Fbl8A0jdt8Pq9eMFxIYCPGjy4vgQho85K5Hp/Fv7fwEel +BG+067sOJsUAbR0iRkuaZYVr3+6ZcOTttkus5BYlNVPDDecF3H0MiC/FQu1fGGs/qR9irUD1ns40 Zpr1yls8aKanpJVAKAgg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1omFwF-00D0PU-MR; Sat, 22 Oct 2022 14:57:27 +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 1omFwE-00D0Ow-Bo for linux-arm-kernel@bombadil.infradead.org; Sat, 22 Oct 2022 14:57:26 +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=LfDdHQU4IT/hl9I/5HNnFT18wMtiD3dXD2LsNJVhO5Y=; b=dCyf9vlwvONBM4zSIsCL3Xkogn uhuZ7ki2qrs2doVxqulA1AE2JiYuCjEPz8IdtufwRps7O4skItg4W7b6DhivXsWUeYn06jdrezoRA cc7FhdHqiTTUJQZ/QiyFGxrzCbiOsWlEinzkbqP+vuySr6F7BFXavWD5WcH7D5AJ7DAQYWEyJ4Al6 cMkJduq0RcpDGmDYiho+MtfVYgU0GUYFB9bOtkbiV0CidzQmY7ghM3dDUCh0iNOYrx0syawZm2wHw ZbW9EWrjF8WGHfM82My18SxLd9yLHpd0t7+tJQnWYbJHrLeqsnHx+9WC9uCpPZRfwChIclGKOGh4Z nIO6WG2A==; Received: from j130084.upc-j.chello.nl ([24.132.130.84] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1omFwD-00DzS4-Nz; Sat, 22 Oct 2022 14:57:25 +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)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 7C40E30035C; Sat, 22 Oct 2022 16:57:19 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 192882C30ED69; Sat, 22 Oct 2022 16:57:19 +0200 (CEST) Date: Sat, 22 Oct 2022 16:57:18 +0200 From: Peter Zijlstra To: Mark Rutland Cc: llvm@lists.linux.dev, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Fangrui Song , Joao Moreira , Josh Poimboeuf , Kees Cook , Nathan Chancellor , Nick Desaulniers , Sami Tolvanen Subject: Re: kCFI && patchable-function-entry=M,N Message-ID: References: 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 Fri, Oct 21, 2022 at 04:56:20PM +0100, Mark Rutland wrote: > Hi, > > For arm64, I'd like to use -fatchable-function-entry=M,N (where N > 0), for our > ftrace implementation, which instruments *some* but not all functions. > Unfortuntately, this doesn't play nicely with -fsanitize=kcfi, as instrumented > and non-instrumented functions don't agree on where the type hash should live > relative to the function entry point, making them incompatible with one another. > AFAICT, there's no mechanism today to get them to agree. > > Today we use -fatchable-function-entry=2, which happens to avoid this. > ... but I understand that for x86, folk want the pre-function NOPs to > fall-through into the body of the function. Yep. > Is there any mechanism today that we could use to solve this, or could we > extend clang to have some options to control this behaviour? So the main pain-point for you is differentiating between function with notrace and those without it, right? That is; suppose you (like x86) globally do: -fpatchable-function-entry=4,2 to get a consistent function signature, you're up a creek because you use the __patchable_function_entries section to drive ftrace and now every function will have it. So perhaps something like: -fpatchable-function-entry=N,M,sectionname would help, then you can have notrace be the same layout, except a different section. Eg. something like: #define notrace __attribute__((patchable_function_entry(4,2,__notrace_function_entries))) It does make the whole: CFLAGS_REMOVE_file.o = $(CC_FLAGS_FTRACE) a bit of a pain, but I've long favoured removing all that and having explitic notrace attributes on all relevant functions. Then again; perhaps it could be made to work by ensuring CFLAGS starts with: -fpatchable-function-entry=4,2,__notrace_function_entries and have CC_FLAGS_FTRACE include (and hence override with) -fpatchable-function-entry=4,2,__ftrace_function_entries assuming that with duplicate argument the last is effective. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel