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 at 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.
>