The KSPP and Linux Kernel Hacking

Linux Kernel Hacking

Ever since I started using Linux in 7th grade, I have been fascinated by and fervently believed in the Free Software Movement and the projects that emerged as a result. One of these projects is the Linux Kernel. Started as a small hobby project and to solve a real problem by developer Linus Torvalds, it is now the most widely used operating system in the world. While nowadays it is mostly funded and developed by corporations, non-trivial amounts of development are done by hobbyists and hackers. Some people work on simple drivers for pieces of hardware that they have that are not yet supported, while others are trying to bring Linux to Apple hardware.

Naturally, I wanted to join the community of kernel hackers (or contributors). I found Greg Kroah-Hartman's video at FOSDEM showing how to write and submit a kernel patch (a fancy word for a piece of code). For those who do not know, Greg KH is Linus's right-hand man. Greg does it all, and is one of the most respected members of the kernel community. Also, funnily enough, while this video was made more than 15 years ago, it is still 100% accurate and relevant. For better or worse, not many projects can say their development process has remained unchanged for 15 years.

After watching the video, I searched through the directories of projects I was interested in. At the time, I was familiarizing myself with SELinux, so I looked through the source tree to try to grok how everything worked and learn the development process. Thankfully, I was fortunate enough that Paul Moore, the maintainer of the SELinux subsystem, was kind and patient enough to take my code. While it did nothing but appease the static code analyzers, it was exciting for 14 year old me! I had contributed to the most prolific operating system in the world. Due to SELinux's use in Android, my code runs on billions of devices around the world. ;)

A few weeks after that, I started poking around in the staging/ directory. This location folder holds all the drivers that have been submitted and accepted upstream but are not yet parts of the core kernel. They remain in staging/ until the code meets style guides and features are more fully flushed out. This is where most beginner contributors start. I fixed a few documentation errors in the comedi driver. Greg KH, who I mentioned above, maintains the staging/ directory. This means that he was the one who responded to my emails and accepted my code. Pretty neat!

The Kernel Self Protection Project (KSPP)

Most of my earlier contributions were pretty insignificant. However, I have found a way to meaningfully contribute needed and valuable security fixes to the Linux Kernel via the Kernel Self Protection Project. Founded by Google employee Kees Cook, the project is dedicated to making the kernel more secure and more resilient to attacks. Specifically, his work focuses on making C safer by default and fixing bugs long before they are ever discovered. Gustavo Silva is another very active contributor. In fact, he has reviewed some of my code, which is neat considering his presentations are responsible for my involvement in the KSPP. Thanks, Gustavo!

While I may not have the knowledge to rewrite a driver from scratch to be more performant or have the skills to reverse engineer Apple hardware, I am capable of critical thinking and analyzing small sections of code in detail. This is what the KSPP is about. Most of the changes within the project are small changes: a few lines of code here or there. Some are as simple as changing a single character from the strncpy function to strscpy! But there is a purpose behind each patch.

There are over 100 open issues on the KSPP's GitHub tracker. Each one focuses on a different part of the Kernel. While some issues focus on working towards the enabling of a compiler flag that hardens the kernel, some are design changes and code changes. One of the easier ones to learn about and understand is the migration from open coded arithmetic to helper functions. Essentially, instead of using kzalloc(nr * sizeof(*int), ...) we should use kcalloc(nr, sizeof(*int), ...). This change not only increases code readability, but there are built in protections within kcalloc against overflows due to casting or memory weirdness. This is a really easy way to contribute and make the code verifiably safer and better.

The past few weeks I have sent a litany of patches on to the mailing lists changing code in the erofs, gpu/drm, scheduler, thermal, and sound subsystems. This has been an excellent way to practice using tools like b4, git rebase, writing good commit messages, and learning the netiquette of email-based workflows. I even found a set of code to practice sending multiple patches, or a series, at once. I sent 4 patches for various AMD drivers in gpu/drm/amd.

Getting started

For those who are interested, I recommend watching the above video and reading the official kernel documentation on contributing. After cloning the source code, run git grep -n kzalloc | grep ' \* ' | grep -v ':\s\+\*' and find instances of code that can be improved! Sometimes while searching for KSPP issues to fix, I come across ways to make the code better in other ways. For example, in the sound subsection I removed more than 30 lines of code by combining two functions.

So, my final advice for readers who are interested in learning to hack on the kernel is to jump in! It takes some persistence, especially when learning the tooling, but the effort is worth it. Find a subsystem that is interesting and exciting and start poking around. Think of ways to improve code, break it, fix it, and do it all over again. It is incredibly gratifying and rewarding to have one's first contribution merged! If this little blog post has inspired anyone to get started and submit their first patch, please CC me on the email and I would be more than happy to review it and provide feedback.