SUBMITTING TO LINUX KERNEL FULL
This has been up for debate within the community as far back, at least, as 2008 as we can seem from this post on the Full Disclosure mailing list from 2008, titled " Linux's unofficial security-through-coverup policy" by as I mentioned earlier, a lot has changed since then, and our perception of security has come a long way since then. It's a complex topic and to over simplify the arguments, on either extreme of the axis you may have folks saying all fixes should be treated equally, while others would argue security fixes need to be dealt with in a specific way, highlighting the impact etc.Ī recurring topic in this space is the concept of "silent security fixes", where a commit fixing a potentially exploitable vulnerability intentionally omits information regarding the security implications/reasons behind the fix. There's been lots of discussion surrounding security fixes and how they should be handled in relation to non-security fixes in the kernel, and this dialogue has understandably evolved over the years as our concept and understanding of security has too. There are several long-term maintenance (aka LTS) kernel releases, to designate support for older kernels. Important to note is the concept of backporting, whereby bug fixes introduced in latest releases are applied to older kernel releases as well. you won't see a bunch of different fixes for different parts of the kernel in one commit, I hope anyway).Īll these changes are organised into releases, which you can read about over at, with new mainline kernels being releases every 9-10 weeks. That's a lot of changes, right? The Linux kernel has guidelines and rules about submitting patches, but typically a commit is a logically cohesive set of changes (i.e. As of writing, the Linux kernel source tree mirror on GitHub has 1,154,596 commits that we can peruse! If we look at projects on GitHub for example, we can see this. A commit describes a set of changes made to the project by an author. Specifically for a project using git, we can track the changes made by looking at the commits. Changes are tracked using the version control system git"
SUBMITTING TO LINUX KERNEL FREE
"The Linux kernel is a free and open-source, monolithic, modular, multitasking, Unix-like operating system kernel Day-to-day development discussions take place on the Linux kernel mailing list (LKML). The original motivation behind this research stems from a somewhat contentious and longstanding topic of discussion amongst the Linux kernel community regarding the handling of security fixes, such as instances of "silent security fixes".įirst of all, to give some context to what we're talking about, let's do a quick tl dr on kernel development and some of the terms mentioned so we're all up to speed! (feel free to skip) kernel dev tl dr Where there are gaps in my understanding or knowledge, I'll try to the highlight them, and if anyone has any corrections or additional info please let me know, thank you! Content I want to highlight that I am by no means an expert on these things, and my thoughts here are from the experiences (and biases) of a security researcher. Disclaimerīefore we dive into things, some of the topics and issues I cover in this post are both complex and contentious. Then I'll do a quick tl dr on the tool, Lica ( Linux Commit Analyser), I wrote and share some takeaways. So in this post I'll talk a little about the background behind the motivations for looking into this and why kernel security fixes is an interesting topic. But instead of putting it on the back burner, AKA never to see the light of day again, I thought I'd share the tool I ended up writing and discuss some background behind it as well as my own takeaways during my time working on this stuff. However, between both IRL circumstances and simply underestimating the time involved, this has dragged on more than I'd like for a blog post to take and I'm eager to move onto new things.
The plan was to do some analysis of Linux kernel commits, to determine the feasibility of automating the process of finding interesting and potentially exploitable vulnerabilities, hopefully putting a novel poc or two together. It's been a while, hasn't it? This post is going to be a bit of a change of pace from usual, as its actually covering some research from last year I ended up dropping.
0 kommentar(er)
