From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f180.google.com (mail-yw1-f180.google.com [209.85.128.180]) (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 EFE1C47D920 for ; Tue, 18 Aug 2026 17:24:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787073889; cv=none; b=XLgxLiN706BJEHCtmaQPWpb4Q2b05GzhpDOSCqmXIXmfWvGhrLfNDcIcc/oCkBZfjAkeuvzBcxCssaYe/959izTrBM+qX1qDkGYuufIo7mBt58FCEPXfewNn3QmRCBNcgrWj5gkjttXA/CmhMdjjfNRpWkDwkuPPGH9rLcDLMlQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787073889; c=relaxed/simple; bh=KoMv95V63+sQ6hHC2/qVIggDOpDkFVCYgeGxf/aedgc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=UA31DDSsI9nA5JDo29JPG9ckMAGMBWJhKn9vswuCeNqYQgNLbO3qqQD6n1Ms9Zemp46OGCOHfv2DTpGi8IGxNFWf6b/YKkRgn46+Vwd+o/DI6G7/KckJC1XgzEfhKaPZrXC+7k5dp/fXV1lrbI9YarguS5+N0GdzS+vNNQ0UNKc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=XKCnfIgQ; arc=none smtp.client-ip=209.85.128.180 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="XKCnfIgQ" Received: by mail-yw1-f180.google.com with SMTP id 00721157ae682-80bb41f7f3cso1928807b3.2 for ; Tue, 18 Aug 2026 10:24:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787073887; x=1787678687; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=bS0udjtsLIre9TBO02jitQ0ARuyv59ZbyY0qyeZCnZc=; b=XKCnfIgQZm3RUNuq7sTtJhwinG2yZsuaHkOd24EhMNz7xESmu9ZxnPV0cVrC9YHdlj ckVacvyxuWuxQZ7i0q8GD5vM6wp1KtmgBqbXxiiR5XLs0vct/92cMhW2Dgg4gMAoJ4k4 qDTnOAy30jjTmr+jm3dRs3zlznaf3lPrZlsRhlZtUJaPiVO7MTKK3k1mJrZLvp+fB41E OWb1t6cjY0ZRolQlYBBm0iq5IGgPSwgXmR3mg0p919qRIZd+a7rOa4maINti7Gb7JkK2 mgrLC+fc7EynlsYDchdYgWJe1rSwfQNEcd8+6ByLK9dpspjs/H+Vr2OyRobSulHaZKMv MK6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787073887; x=1787678687; h=in-reply-to:content-disposition:content-type: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 :content-type; bh=bS0udjtsLIre9TBO02jitQ0ARuyv59ZbyY0qyeZCnZc=; b=WYDEGMGSnfzpI2HG/iXAZAYBSqOpd3gOkc0clN2shcv0eggYD1F5Xoyb+qksXyTVa8 5QqlddkyeK1WIFSztVDCpqh5FB0htng4cUdREiBjmqVv8s459qZXYWP7XLjJti8sIEin qWc1M0KcvEcTTH5mtDVVk25OczvG08Y5DqfqOBLh/BSKCGry9rAn4Em3FgE1OwiC167x xa3R4t9I9zJJAaDgzj6U2AKI3DAxs+zQ/225p4YTG7FtdEPuMVLMzTtLbjmibrzdgYOx ROWqcqU+kgsYB9aiM9y25G8ue+R2dk02vJcptx8ZCDFCH29JLuuYnewSiVwsKaICfQBC OVBA== X-Forwarded-Encrypted: i=1; AHgh+RqM0PIsZ0JyRGc5AN2w9RzS4xjMy7rY0+qcC+pwMPal3qxg9nI+W58KEHHTpW+dnh7+5tfR3ZIEHB/mfE0=@vger.kernel.org X-Gm-Message-State: AOJu0YyJXyKHkBfShvshuFszsijCAlYDFq/ugtvZ4EB1C1qnPnJbNPQN 4d1ZjxFYv9onvWss6A4XhpYLwbI6nr1ZC5Vn0GLN3wwGQqSvbSN695Ko X-Gm-Gg: AR+sD10k8+HMOGTSMn9NtW2mCLGSXPcqc2g/gS/WPOBmFGu7dHg4JrhtRXaLJakL7d7 hypKwXHSfocyQO8+cb42mZsSdCyiRpcukH6GJIi9oL2z9ldmOhifExYoC6KoIB7SnwFJ0zi4EFg hl1N8Rc0g5/f3Bj99ZbbtD899uwbglLZ5lmdHgzQpqp+n5aqY7159P+ZGCn39pEqDfwtbC1gR2H 2wN6W2bCbkXwp6MZ4S7P/lXxsZb6M37uFvoarwYiWAExmvfndZCRATLML9aAnN4KxXeSDO8phih deaFo3LPIT6DVatST3dwnHyUxTNQmVRS19Qk0avgp9MLJ4H3/zVdvVxCMfef9/3QZCZDLNHVJ6/ orZ8UjQfr8xayoJE2oQT5c9/Up8QJXxpmLNg9e8H3/qbiicRLaJqFOdE9nuSXKWR8bL0XN+9VtO qaOiKT1rMimzv0vUMk84IaEn09y741ZcxONk3A53KAOS+tuWPkyME72RP+Iau2gUPs8LwZjy34Z sXy8X4pcFEzfHhkwWSgsYg= X-Received: by 2002:a05:690c:e155:b0:826:5659:28aa with SMTP id 00721157ae682-8371337ca5cmr92410727b3.32.1787073886758; Tue, 18 Aug 2026 10:24:46 -0700 (PDT) Received: from zenbox ([2600:1700:18fb:6011:f3e5:832a:1675:b570]) by smtp.gmail.com with ESMTPSA id 00721157ae682-84068c24d45sm24956597b3.16.2026.08.18.10.24.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Aug 2026 10:24:46 -0700 (PDT) Date: Tue, 18 Aug 2026 13:24:45 -0400 From: Justin Suess To: Kumar Kartikeya Dwivedi Cc: Alexei Starovoitov , Paul Moore , Xiu Jianfeng , linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, bpf@vger.kernel.org Subject: Re: [PATCH bpf-next 0/2] lsm: give BPF programs a way to query locked_down state Message-ID: References: <20260815112041.1248855-1-utilityemal77@gmail.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=us-ascii Content-Disposition: inline In-Reply-To: On Tue, Aug 18, 2026 at 11:42:34AM +0200, Kumar Kartikeya Dwivedi wrote: > On Sat Aug 15, 2026 at 1:20 PM CEST, Justin Suess wrote: > > If you care about knowing the state of lockdown LSM, doing > bpf_probe_read_kernel() etc. should allow reading that state from the program. > If you have a BPF LSM supplying a dynamic verdict in your environment, I don't > see why you cannot use the decision procedure from the same implementation in > other places of the LSM. I doubt you have the scenario where BPF LSM is shipped > by someone else and your program needs access to its decisions instead. > (I've found a workaround with tracepoints that removes the need for this series. Thank you anyway) > Lastly, given the difficulties we've faced from the LSM maintainers, I'm not > inclined to waste more time in explaining again why this cannot go under > security/. > Without wanting to rehash this issue, Both LSM and BPF maintainers, some cc'd in the thread, have worked with me as a new contributor through my mistakes and volunteered their time, expertise, and effort. I cannot appreciate it enough. Clearly, great talent and commitment to making the kernel better lives on both sides of the fence. There's also no question the whole kernel would benefit from better communication between these awesome subsystems. I don't mean to admonish anyone or assign fault. Debates happen, things get heated, it's what happens. But the fact that multiple series are stalled on this because BPF/LSM don't trust each other enough to have shared code ownership implies the current process is broken. This isn't the first instance of this breakdown either. It hurts new contributors caught in the crossfire, maintainers who have to tiptoe around this drama, and kernel users. If anyone is willing: I'd like to set the debates aside and discuss in good faith how we can establish a better process for LSM/BPF review, testing, and integration. So we can steer this conversation to the technical side, which is where actual work happens. That could be an LSM/BPF integration branch, or Documentation/, or something else, or meeting up at a conference and having some beers together. Kind Regards, Justin > pw-bot: cr > > > [...]