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 043A3ECAAA1 for ; Mon, 24 Oct 2022 11:42:34 +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=tAA6KvhfML1/B6GkXFRJfMQRQatehan/7xC6LJhRMjk=; b=0iOi9E7fRgRFar vkWw/3piIruhp6SvTz2aWMNP+0UvCcVcvOe4IqzjgudZln4DCe65MGVDqXE/QCrniCjc0UEyoFlxT bqCJtLmqSx26CGna/8mwW4dlM/gX925TtoZ4QBY3N/8X89VtvcKyHFpIsS1aT1CBimq48ZnNZrhWb Sc2rzgY6Sjpj1MIYCK/T7vc3G2CC4mqyecvHLFUN3ehiBfiSMjKly6p2ERvODuSeUZFrPUP+XtXNo cutFncoazMyKPRYTQm2C8xhDnVU7/hcQc7WKB62clNnf68qIKtCO/bYQSspo478p+suhEGtuwBJ/q v0kNkMr6gG5E5eJ9Sorg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1omvpX-00197s-Oa; Mon, 24 Oct 2022 11:41:20 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1omvZ4-0010DG-Ea for linux-arm-kernel@lists.infradead.org; Mon, 24 Oct 2022 11:24:20 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 22B21D6E; Mon, 24 Oct 2022 04:24:22 -0700 (PDT) Received: from FVFF77S0Q05N (unknown [10.57.7.186]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1F3BF3F7B4; Mon, 24 Oct 2022 04:24:13 -0700 (PDT) Date: Mon, 24 Oct 2022 12:24:11 +0100 From: Mark Rutland To: Peter Zijlstra 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-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221024_042418_577275_0D319685 X-CRM114-Status: GOOD ( 28.16 ) 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 Sat, Oct 22, 2022 at 04:57:18PM +0200, Peter Zijlstra wrote: > 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))) FWIW, I think that'd work for me, and that was roughly my original proposal on IRC. My only concern with this approach is code size, since all uninstrumented functions gain some point less prefix NOPs. We can make that slghtly better as: #define notrace __attribute__((patchable_function_entry(2,2,__notrace_function_entries))) ... since we don't care about placing NOPs *within* the function > 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. TBH, it'd be nice to move ftrace to the `CFLAGS_WHATEVER_obj.o := n` approach the other instrumentation uses, which IIUC would allow us to define different flags for the two cases (though I'll need to go check that). Thanks, Mark. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel