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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D325BC25B0E for ; Mon, 15 Aug 2022 15:33:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233077AbiHOPdS (ORCPT ); Mon, 15 Aug 2022 11:33:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47326 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231978AbiHOPcx (ORCPT ); Mon, 15 Aug 2022 11:32:53 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 232E41EEE1; Mon, 15 Aug 2022 08:32:37 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id B4766610A2; Mon, 15 Aug 2022 15:32:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5B4ECC433C1; Mon, 15 Aug 2022 15:32:34 +0000 (UTC) Date: Mon, 15 Aug 2022 11:32:40 -0400 From: Steven Rostedt To: Alexei Starovoitov Cc: Peter Zijlstra , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Ingo Molnar , bpf , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Hao Luo , LKML , Josh Poimboeuf Subject: Re: [RFC] ftrace: Add support to keep some functions out of ftrace Message-ID: <20220815113240.71edf5cf@gandalf.local.home> In-Reply-To: References: <20220722174120.688768a3@gandalf.local.home> <20220813150252.5aa63650@rorschach.local.home> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Mon, 15 Aug 2022 08:17:42 -0700 Alexei Starovoitov wrote: > Ask yourself: should static_call patching logic go through > ftrace infra ? No. Right? I agree that static_call (and jump_labels) are not part of the ftrace infrastructure (but ftrace was a strong motivator for those). > static_call has nothing to do with ftrace (function tracing). Besides the motivation, I agree. > Same thing here. bpf dispatching logic is nothing to do with > function tracing. But it used fentry, which is part of function tracing. Which is what I'm against. And why it broke ftrace. > In this case bpf_dispatcher_xdp_func is a placeholder written C. > If it was written in asm, fentry recording wouldn't have known about it. And I would not have had an issue with that approach (for ftrace that is). But that brings up other concerns (see below). > And that's more or less what Jiri patch is doing. > It's hiding a fake function from ftrace, since it's not a function > and ftrace infra shouldn't show it tracing logs. > In other words it's a _notrace_ function with nop5. On the ftrace side, I'm perfectly happy with Jiri's approach (the one I help extend). But dynamic code modification is something we need to take very seriously. It's very similar to writing your own locking primitives (which Linus always says "Don't do"). It's complex and easy to get wrong. The more dynamic code modifications we have, the less secure the kernel is. Here's the list of dynamic code modification infrastructures: ftrace kprobes jump_labels static_calls We now have the bpf dispatcher. The ftrace, kprobes, jump_labels and static_calls developers work together to make sure that we are all in line, not breaking anything, and try to consolidate when possible. We also review each others code. The issue I have is that BPF is largely doing it alone, and not communicating with the others. This gives me cause for concern on both a robustness and security point of view. -- Steve