On 4/9/2025 11:49 AM, Paul Moore wrote:
> The LSM currently has a lot of code to maintain a list of the
> currently active LSMs in a human readable string, with the only
> user being the "/sys/kernel/security/lsm" code. Let's drop all
> of that code and generate the string on an as-needed basis wh
On 4/10/25 15:47, Paul Moore wrote:
On Wed, Apr 9, 2025 at 7:13 PM Kees Cook wrote:
On Wed, Apr 09, 2025 at 02:49:53PM -0400, Paul Moore wrote:
The LSM currently has a lot of code to maintain a list of the
currently active LSMs in a human readable string, with the only
user being the "/sys/ke
On Thu, Apr 10, 2025 at 10:15 PM Kees Cook wrote:
> On Thu, Apr 10, 2025 at 06:47:12PM -0400, Paul Moore wrote:
> > On Wed, Apr 9, 2025 at 7:13 PM Kees Cook wrote:
> > > Better yet, do this whole thing in a initcall after LSMs are loaded, and
> > > both can gain __ro_after_init...
> >
> > I *real
On Thu, Apr 10, 2025 at 06:47:12PM -0400, Paul Moore wrote:
> On Wed, Apr 9, 2025 at 7:13 PM Kees Cook wrote:
> > Better yet, do this whole thing in a initcall after LSMs are loaded, and
> > both can gain __ro_after_init...
>
> I *really* disliked all the stuff we were having to do during boot,
>
On Wed, Apr 9, 2025 at 7:13 PM Kees Cook wrote:
>
> On Wed, Apr 09, 2025 at 02:49:53PM -0400, Paul Moore wrote:
> > The LSM currently has a lot of code to maintain a list of the
> > currently active LSMs in a human readable string, with the only
> > user being the "/sys/kernel/security/lsm" code.
On Wed, Apr 09, 2025 at 02:49:53PM -0400, Paul Moore wrote:
> The LSM currently has a lot of code to maintain a list of the
> currently active LSMs in a human readable string, with the only
> user being the "/sys/kernel/security/lsm" code. Let's drop all
> of that code and generate the string on a
