Difference between revisions of "Kernel Self Protection Project/Get Involved"
Line 1: | Line 1: | ||
Want to get involved? [http://www.openwall.com/lists/#subscribe Join] the [http://www.openwall.com/lists/kernel-hardening/ kernel hardening mailing list]. | Want to get involved in the [[Kernel Self Protection Project]]? [http://www.openwall.com/lists/#subscribe Join] the [http://www.openwall.com/lists/kernel-hardening/ kernel hardening mailing list]. | ||
= Introduce Yourself = | = Introduce Yourself = |
Revision as of 23:39, 5 June 2017
Want to get involved in the Kernel Self Protection Project? Join the kernel hardening mailing list.
Introduce Yourself
Send an email to introduce yourself! Then pick an area of work from below (or add a new one), coordinate on the mailing list, and get started. If your employer is brave enough to understand how critical this work is, they'll pay you to work on it. If not, the Linux Foundation's Core Infrastructure Initiative is in a great position to fund specific work proposals. We need kernel developers, compiler developers, testers, backporters, a documentation writers.
Patch Contribution Guidelines
When contributing patches for the Linux kernel, be sure to follow the Linux kernel Coding Style Guide and read about Submitting Patches. Even if you're only sending your patches to the kernel-hardening mailing list for some early review, it's best to get as much of the coding style and submission semantics correct to avoid reviewers needing to recommend changes in those areas.
As with any other Open Source project, it is particularly important that if you're working on upstreaming work from other Open Source projects, be sure your patches are giving credit to the original authors, that licenses are compatible, and that copyright notices are retained, etc.
In the case of new files, or other places where a copyright notice would be expected to be added, be sure to retain all copyright notices from the other project. This may require some examination of commit history. For example, Grsecurity's copyright notice from their most recent public patch does not include PaX Team's copyright notice, which is only listed in the patch for GCC plugins. For Grsecurity copyright, when more specific details are not easy to find, the following could be used:
Copyright (C) 2001-2017 PaX Team, Bradley Spengler, Open Source Security Inc.
Additionally, Grsecurity has asked that contributors include this in commit messages for non-trivial code ported from Grsecurity:
$CODE is {verbatim,modified} from Brad Spengler/PaX Team's code in the last public patch of grsecurity/PaX based on my understanding of the code. Changes or omissions from the original code are mine and don't reflect the original grsecurity/PaX code.