From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f177.google.com (mail-yw1-f177.google.com [209.85.128.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 551E317A300 for ; Wed, 22 Apr 2026 18:50:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.177 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776883847; cv=none; b=Z30prrJ6nnG4ONIq2AfuugasCZ0lA90JI4SWy9nkQ2ZWhhyRbI5pCpRknqJZVZvzMJjG1g2aMcPfymjpa97Pb/agdB5c6gUWsHlPoNYmqkHmIY30yekT14KQTbW3m9bxzs54qDmUkXXrKrvHQmpILKZZAA2U37PLojzVeNam4HQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776883847; c=relaxed/simple; bh=ic2g+3H1Bjt8Eoenl8C/wnTWLiAcZvj+NJ4io3SQ8Y4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=RWPyk2HRPR+h1dVL67Q3otwtQmWiScE+Vq8tdBZLUoJbPsapMv3BG91en3V3PlO/Wj5K5XjK694krpbw+KXiLrPPAHQzqCycWioXv5lE4qTYYnwvUj3501+DaqoPk7KVxO1Lgq3ukavAjcheeU1jWW+orKlc3Nxq80UxNj/FfAo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=cloudflare.com; spf=pass smtp.mailfrom=cloudflare.com; dkim=pass (2048-bit key) header.d=cloudflare.com header.i=@cloudflare.com header.b=IwYpqDKm; arc=none smtp.client-ip=209.85.128.177 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=cloudflare.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=cloudflare.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=cloudflare.com header.i=@cloudflare.com header.b="IwYpqDKm" Received: by mail-yw1-f177.google.com with SMTP id 00721157ae682-79a46ebe2beso60049397b3.2 for ; Wed, 22 Apr 2026 11:50:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google09082023; t=1776883844; x=1777488644; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=NfY2mNb6T4MB2zH44et65lOJxNFCx009tFohO2VhSnE=; b=IwYpqDKmG67OEyUOuXSHQ8a+NIVvM+dBOrf9IsGH8Xq9K1F8tZmqXgBJ7KSutUqzYO udOwG8n8aojk9T2SE/41dxAjH6sGzozgUceMQpC96Nv9hqmga+lhf7CUSBzDfWDvaPCU hkGwGhB5FUM2WUNpot9gmd76sJg5kk9XlOSe5vqitiGFYf0X1kyTlsa9TwGIDgzjGg/5 9xv/psJozsTIEy9d4CxiygIDjYbcha+oPXr2+icOmdRJg1vr5pa3tGnuAzC2jYhKVTTC fdMfL9fjuGfSHeTU98grv5fkO+Ntc9LwHB1eNOJM9w9F5Ey05ELuFDj8HRJ9B0cUWzSH pkqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776883844; x=1777488644; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=NfY2mNb6T4MB2zH44et65lOJxNFCx009tFohO2VhSnE=; b=OmPAq2OCLDF9abK+pV8b96GW3q7D8mM23Vfka8mhIrFEY/nYAxC53CiX/EA+ITQt7H BZTp8fjHlAhMCXoQ7i/s1c9VMddPzn91Whs3FEIv8Vb0d9A9a1ReIGdI0HOu1kO90oYr uERYU+qdBjeaspR+euqIQfd2u60Oo/A3/MJXtWqJVlJjg1sBZ5fxozwTQFwpIMvNnwvd +GL5SELFVLS8aN9QPX8JIn1VxoA60BItf9SRasRPe0OLoE6ExPpptj8Bmot+Ih9CE0f9 DpD89CH9jbmv5sUoXSmeqGJfkFCAP0cHw8TpNtcvuR39/5Eh/GYdEwe7v21MnEQ+v0Nc GP/A== X-Forwarded-Encrypted: i=1; AFNElJ9V3S6W3WV4q9wlFh04AsS2WMlj5y2EaO5OxPsZPPN8iYBrB630pkN0NoohcMrDn3+EPYC6u7OqtXXHG2s=@vger.kernel.org X-Gm-Message-State: AOJu0YzNTkvUbTe3x4ojKYshF6/KBY9f5XvEx/AzX0c0Ja9ZF/SZeeWB LWnVx3hvWsEV/SDTML9J2Al8tU2/sH+hk7Gf0+ERgHylXR5JNq0r1H+p/08MNGasYGc= X-Gm-Gg: AeBDieuViYwrU2tU+T9bmpnlUb82IZF4WMLSBGgnEbe4PgT+lRH8a6eTreYclEVUtEO AdIbLqRJE67KEVe1+h4Kdt1iGi+mNkVpXyyvDva7CtSxmDKpJpef2dPw+sK6xdp93UOu7FxMAMc BuG0vo84nhd1twp2dutC+7WP50774XGUQsKHvOI8C0cYpVYQphuHFJjsUlbkAG0QJAbHswiypzU qLKxBcFsDBwLNsoXA1f3bRWG92PILOOG0nvCV9UolR15LlYjakG/D1JS30tKz1bXw2WKU+Iic8n QMfT9wn2IewBn5PPtOlbBHKsJMK1p3DPo/8FyopYL0D8OD78bZUvpbJCT7QpJAwKDHhcHdUKqB7 tWF1491Du0FcAvFXjlOoBJCGcLcVFnTJkTx7efBWGdtePtuECfAcWkruOZqdkhLOrI6XvIum4O1 3jNi+P8dK2neJx X-Received: by 2002:a05:690c:7283:b0:79b:e24e:e2f8 with SMTP id 00721157ae682-7b9eccb6dfemr246497157b3.0.1776883844180; Wed, 22 Apr 2026 11:50:44 -0700 (PDT) Received: from CMGLRV3 ([2a09:bac6:947f:3af::5e:42]) by smtp.gmail.com with ESMTPSA id 00721157ae682-7b9ee89abbfsm71419907b3.10.2026.04.22.11.50.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Apr 2026 11:50:43 -0700 (PDT) Date: Wed, 22 Apr 2026 13:50:40 -0500 From: Frederick Lawler To: Paul Moore Cc: Alexei Starovoitov , Linus Torvalds , James Morris , "Serge E. Hallyn" , Eric Paris , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Eduard Zingerman , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa , Shuah Khan , =?iso-8859-1?Q?Micka=EBl_Sala=FCn?= , =?iso-8859-1?Q?G=FCnther?= Noack , LKML , LSM List , audit@vger.kernel.org, bpf , "open list:KERNEL SELFTEST FRAMEWORK" , kernel-team Subject: Re: [PATCH RFC bpf-next 0/4] audit: Expose audit subsystem to BPF LSM programs via BPF kfuncs Message-ID: References: <20260311-bpf-auditd-send-message-v1-0-10a62db5c92f@cloudflare.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Hi Alexei & Paul, Thanks for the comments. I did not mean for the talk announcement to end in this state. I understood the RFC was NACK'd, but I thought having a talk at LSS could open up for some additional discussion around what can be done with audit to make it more BPF friendly. I apologize. My assumption is that the committee would've denied the talk if there wasn't _some_ interest here. And still intend to give it unless committee decides to revoke it, because there is always opportunity to improve subsystems. On Wed, Apr 22, 2026 at 10:33:27AM -0400, Paul Moore wrote: > On Tue, Apr 21, 2026 at 7:08 PM Alexei Starovoitov > > Every time somebody adds a kfunc it breaks safety, because > > people don't read or don't understand Documentation/bpf/kfuncs.rst. > > kfuncs are not export_symbol. > > Object ownership model needs to be thought through. > > Calling context needs to be analyzed and so on. > > Just because something "works for me" it doesn't mean > > that it's safe. I interpreted this comment as more broadly applied to patch submissions in general, and not this patch series itself (necessarily). I do think that "... it breaks saftey ... kfuncs are not export_symbol" is what the crux here is. I argue that that Documentation/bpf/kfuncs.rst should be improved if this is a common trap that I and others fall in. As I understood kfuncs, the point is to move away from BPF helpers so that subsystems can have a export_symbol of sorts. To quote: BPF Kernel Functions or more commonly known as kfuncs are functions in the Linux kernel which are exposed for use by BPF programs Unlike normal BPF helpers, kfuncs do not have a stable interface and can change from one kernel release to another. ... As Paul mentioned, there are examples of the export_symbols use case, and even one whose sole purpose is to crash the kernel: crash_kexec()[1] And to be clear, I don't think that is a bad or uneeded patch. I just find it interesting and unexpected that it was applied. Maybe this series is the straw that breaks the camel's back? > > Unfortunately that isn't the review you provided Fred in this thread. > There were no comments about object ownership, calling context, > safety, etc., only a dismissive comment telling Fred to use something > else for logging. If you want to provide proper feedback, something > along the lines of Kumar's constructive review, I think Fred would > welcome that. > Agreed. I can work with addressing calling context and object ownership concerns. I thought I addressed these, but I'd like to know if there's something I didn't consider. Best, Fred [1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=133790596406ce2658f0864eb7eac64987c2b12f