From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ot1-f50.google.com (mail-ot1-f50.google.com [209.85.210.50]) (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 C4BD6306D3F for ; Wed, 18 Mar 2026 17:49:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773856194; cv=none; b=paITKMWOu4cibO2vaGduDya2rPRgnypk9AY8HkW0m7C0Fyvtx078fC6+BXYNeECW6ZOe2/i6ZSg0MaebZP7YDNIRiibDR1ICwnIiC30uHDkz24SEolv9Y0Z5uKQhTGu7a2UTt0ENYmnNi1UQA595qW0LsaSccOxiBw4WtXedfCY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773856194; c=relaxed/simple; bh=HGCegGKd/wL01yykR6BtOd16uHaQDYMxuA7939bT0Ac=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=fZQBY9XqsfyXZljLOUsZi0iisdsekyUpF2Pqur79lHqAXqjMMdZW6xovmb0RsNBZWKxOS5grK8CIVsSkmLF6iCmxpZsMqXmt1yGzMsKjhqhBxPxpiRXC2tIP+j5YjVNVmUTUsFHzdccBdHUdv6oDA0EmagDe1Y5qyjh61LJeW2c= 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=CUvwReGQ; arc=none smtp.client-ip=209.85.210.50 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="CUvwReGQ" Received: by mail-ot1-f50.google.com with SMTP id 46e09a7af769-7d744d9acbeso55563a34.1 for ; Wed, 18 Mar 2026 10:49:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google09082023; t=1773856192; x=1774460992; 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=DwZzEUBvZTlA64oHuhM8Cu6PFpv3s+PziJS94hKbClM=; b=CUvwReGQONVpYZsnOprkScrRcNCgbCu+nCgzLBt1zlng+nXeh8HWMFnX0FiDkfdFAt zMPzDSRqAez68f4L5nKycu9km5fvjHTyzdYEDFKWpTg1KbQ2tsf19LNoiKnfue0l3cZ8 rdSel2wcFNrvEARgczNTw7Mu6f0gUz7w55BPqz/4TRBDzZSKlGwGEX0wlDQuc/D2TGeU 1+RqrKZGMyoSweO2/HpG/QDicGASfKopbkS6YkyyjBPAJjhhyWNJ2laSY0jLa/kZdQeb Zf28KP6sGPtixBR5yWg2aV0Dp6/06Ap6yUePYsYyb63SwSbkebWRHdAW2mBWrD+fF8MA xLTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773856192; x=1774460992; 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=DwZzEUBvZTlA64oHuhM8Cu6PFpv3s+PziJS94hKbClM=; b=Qopkhw3pQCsbFFablBIuZVB5CBxNdZ01CxhTnKj90P4SFEdkMOwHUkCJnFcGEFef2b Xl5lmMFBNqYgCEOVzE7pbuH87ygAj3XWYek77TkGRC3o1TXkphclGhmJ9tz96Buowbic 3oJYomVxZP7LvVCRa5veRZzimA7IC5POqWsRQ33FbRKuQpVimTD4G7rJxT5X0mXbTOag LquUvexxjRlswSAJONuJQOyh0NlZHYFzlt1yip846e+/x9rUSbhLx6uVBD+BRmpVb/ph UIAlf+0tET1d4URzEmaaUK5uW8tubo/z3atLQp8KIweZU4qXF3z94IihnOSIANPF0qyW cDyw== X-Forwarded-Encrypted: i=1; AJvYcCURhaUtQ+qptqRVIPCbmF9rpNhnWPd5OOZHCVndl4WPRZJgm83XATXHItNIwALpXrqCQKGsetvN1E3P+ng=@vger.kernel.org X-Gm-Message-State: AOJu0Yxopi8Z0dnWmAs2VmOELoUYoyvMDrtKjdpLkOUCPkf7Y6yYWgkT 9sL2D7OjLs8EutOkxiwq3aIqPZLOHr8I1SH5fJVqqTm8jbiM47CVwetCBZfy8O3jbIM= X-Gm-Gg: ATEYQzzBaLBFZIBtW65pPuBSlMOls1BwyzO/zxTb/wE8145Vk8+9TkT0GksX29i7RjU US0jfxCQot7ox0RJWGGpbj1WbAFExgpKbTW4Rq79gG+vRqzQlGHSaBCg729S0qoxNfvCmlLFKR8 lTUSYzrCf44iN0cg+KgioZXcsfVmd58HYF+AgS2t0GA87qlHMJZBOVMVJcVRzmbsuLoaQWIYZA5 YOObxKzoBvgJX0KoMloz572RN3iuIp0XLlmV73vabeWheDEH0lhqPqga6tIwBx+0dcIdaH8Kofg +aTX56NlsaSOd/pdgLu5t4qJi61YmI4YIoYlTJb7VJPlERAqRr6A1UDd/tJUds5h3cs2MxlygoO shQDNDwnrax8MZWCECejFQt3Nig+dwmLDwoGdno3yWmV8ihDBs2tDs7p3jNqp7vYRyr0U9+LbBw s9Ag/P X-Received: by 2002:a05:6830:82bd:b0:7d7:d216:2b26 with SMTP id 46e09a7af769-7d7d2163d29mr1417083a34.4.1773856191557; Wed, 18 Mar 2026 10:49:51 -0700 (PDT) Received: from CMGLRV3 ([2a09:bac5:947d:1b37::2b6:4e]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-7d7c9b3696asm2632316a34.16.2026.03.18.10.49.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Mar 2026 10:49:51 -0700 (PDT) Date: Wed, 18 Mar 2026 12:49:48 -0500 From: Frederick Lawler To: Alexei Starovoitov Cc: Kumar Kartikeya Dwivedi , Paul Moore , 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, On Tue, Mar 17, 2026 at 06:15:59PM -0700, Alexei Starovoitov wrote: > On Mon, Mar 16, 2026 at 7:44 PM Kumar Kartikeya Dwivedi > wrote: > > > > On Wed, 11 Mar 2026 at 22:31, Frederick Lawler wrote: > > > > > > The motivation behind the change is to give BPF LSM developers the > > > ability to report accesses via the audit subsystem much like how LSMs > > > operate today. > > Sure, but bpf lsm-s don't need to follow such conventions. > audit is nothing but a message passing from kernel to user space > and done in a very inefficient way by wrapping strings into skb/netlink. > bpf progs can do this message passing already via various ways: > perfbuf, ringbuf, streams. > Teach your user space to consume one of them. Audit provides additional functionality by keeping messages close to the syscall, and in-line with other messages for that syscall. Aside from that, BPF is arguably too flexible. I'm sure it's already understood, but the idea here is to reduce bespoke logging implementations and reduce attack surface for violation reporting. Audit is already provided by the kernel and a well leveraged pipeline. WRT to performance characteristics, would you rather see this implementation leverage those maps in a way to reduce that, background workers, or something else? This is something we've considered, but left out of RFC to collect more opinion on perf considerations. Thanks for bring this up. I forgot to include that in the RFC cover, sorry. Best, Fred