In Part 1, I installed CouchDB, loaded CVE data into it, and ran a simple Mango query that listed the Linux kernel vulnerabilities for a chosen date range for all severities and all kernel versions.
Here, in Part 2, I will extend and refine that query to see results by severity and kernel version. But rather than run queries repeatedly, I will use the power of the command line to semi-automate the process, and Gnuplot will chart the results.
Which is the best Linux kernel?
Linux kernel developers tell us that the ‘best’ Linux kernel to use is the one that comes with whatever distribution we’re using. Or the latest stable version. Or the most recent long-term support (LTS) version. Or whatever one we want, so long as it’s maintained.
Choice is great, but I’d rather have a single answer; I just want the best. The trouble is, for some people, best means fastest. For others, the best is the one with the latest features, or a specific feature. For me, the best Linux kernel is the safest one.
Live patching is a way of updating a Linux kernel without interruption.
Because kernel updates don’t take effect until the system is rebooted, Linux kernel live patching is most commonly used to patch severe Linux kernel vulnerabilities without rebooting servers.
Aside from improved service continuity and uptime, organizations with large server fleets also use live patching to avoid the administrative overhead associated with the coordination and planning needed to reboot multiple systems.
This tutorial will show how to use Kpatch to change the behavior of a running Debian 10 kernel without stopping it, changing the contents of /proc/uptime (and the uptime command) so that the system’s reported uptime is 10 years greater.
Were you at AWS re:Invent 2019?
I was, and it was a revelation.
“Will you reboot your Linux server in the next 30 days?”
That’s what I asked almost everyone who came to the KernelCare stand.
A third of you said yes. The main reason? Compliance.
