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 4F3ECE748ED for ; Sun, 1 Oct 2023 15:44:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235112AbjJAPoX (ORCPT ); Sun, 1 Oct 2023 11:44:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34434 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234846AbjJAPoX (ORCPT ); Sun, 1 Oct 2023 11:44:23 -0400 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6BABDD3 for ; Sun, 1 Oct 2023 08:44:21 -0700 (PDT) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 58FC6C433C7; Sun, 1 Oct 2023 15:44:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1696175061; bh=/IsxbXaX8ShRWS7iabtsMjh/RPNy74azDw8MnY7ouUY=; h=Date:From:To:CC:Subject:In-Reply-To:References:From; b=pPGl0/a3hN0QDnnZUXEY/nvf8D2fGZ78ZGJIWoHvZqW58MhXdNi0P8kPVPaEgYuhC GxF6CrcV2nVuB7TzlvmsvZziyoq4qKUG3RPjD8pJNGpdpFyUbfSqHKufYLQ7NCsiHz LzkVBCAu9UA0WbW6c6UHUNvlKaQ/MgXBVMP0rrtJa68tI+hsw7Y7ujXGckp0h1+Ql4 zOLk9fvY5qYTlbjEnzY/oV9VrmBwbPq82RMREMl9ByYyK6EC4oMb6SXwRzSAHYRV9z NF829XrP3R9rkikN/OSrXf1iZgNH4x4twlHfkqy6PHhB2hk/viNJugFpMDCHoWo2ZG VNwFG/WWo7f/Q== Date: Sun, 01 Oct 2023 08:44:15 -0700 From: Kees Cook To: Tetsuo Handa , Casey Schaufler , linux-security-module , KP Singh , Paul Moore , bpf CC: Kees Cook , Linus Torvalds Subject: Re: [RFC PATCH 1/2] LSM: Allow dynamically appendable LSM modules. User-Agent: K-9 Mail for Android In-Reply-To: References: <57295dac-9abd-3bac-ff5d-ccf064947162@schaufler-ca.com> Message-ID: <06BC106C-E0FD-4ACA-83A8-DFD1400B696E@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: On October 1, 2023 4:31:05 AM PDT, Tetsuo Handa wrote: >Kees Cook said there is no problem if the policy of assigning LSM ID valu= e were > > 1) author: "Hello, here is a new LSM I'd like to upstream, here it is= =2E I assigned > it the next LSM ID=2E" > maintainer(s): "Okay, sounds good=2E *review*" > > 2) author: "Hello, here is an LSM that has been in active use at $Place= , > and we have $Xxx many userspace applications that we cannot= easily > rebuild=2E We used LSM ID $Value that is far away from the = sequential > list of LSM IDs, and we'd really prefer to keep that assign= ment=2E" > maintainer(s): "Okay, sounds good=2E *review*" > >and I agreed at https://lkml=2Ekernel=2Eorg/r/6e1c25f5-b78c-8b4e-ddc3-484= 129c4c0ec@I-love=2ESAKURA=2Ene=2Ejp =2E > >But Paul Moore's response was > > No LSM ID value is guaranteed until it is present in a tagged release > from Linus' tree, and once a LSM ID is present in a tagged release > from Linus' tree it should not change=2E That's *the* policy=2E > >which means that the policy is not what Kees Cook has said=2E These don't conflict at all! Paul is saying an ID isn't guaranteed in upst= ream until it's in upstream=2E I'm saying the id space is large enough that= you could make a new out of tree LSM every second for the next billion yea= rs=2E The upstream assignment process is likely sequential, but that out of= sequence LSMs that show a need to be upstream could make a case for their = existing value=2E But again, I've already demonstrated how there is nothing technical blocki= ng out of tree LSMs=2E If you want a declarative statement that some theore= tical code will land upstream, you will not get it=2E And that's just norma= l FLOSS development: any number of technical, social, or political things m= ay cause code to go unaccepted=2E -Kees --=20 Kees Cook