The Linux universe has changed forever. Its technology is no longer "something strange" in IT conversations, and today it is present in millions of smartphones, tablets, modems, routers, wearables, and vehicles, not to mention its dominance in the server space. With the so-called Internet of Things knocking on the door, the security of the Linux kernel cannot continue with its current model, and multiple voices recommend implementing a new strategy that allows the kernel to "protect itself", staying one step ahead of vulnerabilities.
The update problem
Two meters from my desk, an old smartphone with Android 2.3 collects dust, now serving as a flashlight. Though all I need to do to return it to its original role as a smartphone is insert a chip, the OS version is so old that I'm not sure it's worth the risk. Millions of devices with a Linux kernel in the background are in the same situation. They are robust, flexible, and stable, but without updates, they become insecure. Developers, manufacturers, distributors, connectivity providers, and users all carry a share of the blame. Add the potential of the Internet of Things, and we're talking about millions of additional devices completely at risk. Some of those gadgets are expected to work for five or ten years without a single update, and with that mechanic, the Linux kernel is caught between a rock and a hard place.
Why the kernel can't keep chasing bugs
In other words, the Linux kernel cannot keep chasing bugs. According to Kees Cook, a developer at Google and head of the Linux Kernel Self-Protection Project, the "lifetime" of a bug in the kernel (from introduction to patch) ranges between 3.3 and 6.4 years. These gaps have become unacceptable, and attackers carefully watch every new "commit" to detect and exploit bugs. That shapes advanced kernel protection as a fundamental mission, but there's another problem: 85 percent of kernel bugs do not arise from its core but from integrated drivers. The low quality control demonstrated by some manufacturers is worrying and contributes to the security uncertainty the kernel faces.
The political challenge
Now, the challenges are not only technical, but also political. A trained eye will notice that this "conflict" has much in common with the "monolithic kernel vs. microkernel" debate that stirred Linux enthusiasts more than once and remains a source of notable exchanges. Still, as I said at the beginning, the Linux universe has changed forever. New security problems require new solutions, and a kind of "general immunity in the kernel" doesn't sound so bad. Moving drivers out of the kernel and shifting their operation to "userland" is far from a magic solution, but that's the point: we don't need magic solutions but robust solutions that protect the kernel in the long term. Kees Cook's talk lasts just over 45 minutes and details some of the advances made by the Self-Protection Project, plus additional suggestions for the future. If this topic appeals to you, it's worth watching.
