Improved guidance for LSM submissions.

Improved guidance for LSM submissions.

[Dr. Greg]

Good morning Paul, I hope this note finds your week going well and you
were able to have enjoyed a pleasant holiday season.

The Linux security community has benefited from your prescriptive
guidelines for the sub-system that you developed when you took over
the maintainership role.

What is not clear in these guidelines is how a virgin LSM should be
structured for initial submission.  Moving forward, we believe the
community would benefit from having clear guidance on this issue.

It would be helpful if the guidance covers a submission of 10-15 KLOC
of code and 5-8 compilation units, which seems to cover the average
range of sizes for LSM's that have significant coverage of the event
handlers/hooks.

We will look forward to your reflections and guidance on this issue.

Have a good remainder of the week.

As always,
Dr. Greg

The Quixote Project - Flailing at the Travails of Cybersecurity
              https://github.com/Quixote-Project

Re: Improved guidance for LSM submissions.

[Paul Moore]

On Thu, Jan 8, 2026 at 11:08 AM Dr. Greg <greg@enjellic.com> wrote:
>
> What is not clear in these guidelines is how a virgin LSM should be
> structured for initial submission.  Moving forward, we believe the
> community would benefit from having clear guidance on this issue.
>
> It would be helpful if the guidance covers a submission of 10-15 KLOC
> of code and 5-8 compilation units, which seems to cover the average
> range of sizes for LSM's that have significant coverage of the event
> handlers/hooks.

I would suggest looking at the existing Linux kernel documentation on
submitting patches, a link is provided below.  The entire
document/page is worth reading in full, but the "Separate your
changes" section seems to be most relevant to your question above.

https://docs.kernel.org/process/submitting-patches.html

Beyond that general guidance, at this particular moment I do not have
the cycles to draft a LSM specific recommendation beyond what has
already been documented and reviewed.  As usual, the mailing list
archives are also an excellent resource that can be used to
familiarize yourself with community norms and expectations.

-- 
paul-moore.com

Re: Improved guidance for LSM submissions.

[Casey Schaufler]

On 1/9/2026 10:51 AM, Paul Moore wrote:
> On Thu, Jan 8, 2026 at 11:08 AM Dr. Greg <greg@enjellic.com> wrote:
>> What is not clear in these guidelines is how a virgin LSM should be
>> structured for initial submission.  Moving forward, we believe the
>> community would benefit from having clear guidance on this issue.
>>
>> It would be helpful if the guidance covers a submission of 10-15 KLOC
>> of code and 5-8 compilation units, which seems to cover the average
>> range of sizes for LSM's that have significant coverage of the event
>> handlers/hooks.

Good day Greg, I hope you are well.

If you would review the comments I made in 2023 regarding how to
make your submission reviewable you might find that you don't need
a "formal" statement of policy. Remember that you are not submitting
your code to a chartered organization, but to a collection of system
developers who are enthusiastic about security. Many are overworked,
some are hobbyists, but all treat their time as valuable. If you can't
heed the advice you've already been given, there's no incentive for
anyone to spend their limited resources to provide it in another
format.

> I would suggest looking at the existing Linux kernel documentation on
> submitting patches, a link is provided below.  The entire
> document/page is worth reading in full, but the "Separate your
> changes" section seems to be most relevant to your question above.
>
> https://docs.kernel.org/process/submitting-patches.html
>
> Beyond that general guidance, at this particular moment I do not have
> the cycles to draft a LSM specific recommendation beyond what has
> already been documented and reviewed.  As usual, the mailing list
> archives are also an excellent resource that can be used to
> familiarize yourself with community norms and expectations.
>