Starting to write up a series of articles about the Linux kernel CVE work that has happened in the past 2 years, starting with some "back to basics" information about how Linux kernels are numbered as many people/companies really don't know how we do this, and it matters a lot in tracking bugfixes and how to determine "vulnerable" and "fixed" kernel releases: and
My seat name tag for the EU CRA meeting today... image
Given the news of the potential disruption of the CVE main server, I've reserved 1000 or so ids for the kernel now, which should last us a few weeks.
Scariest cable I have that I actually use. It's a USB-C to Thinkpad "adapter" that I bought to power a thinkpad that shipped with a giant 135W brick-of-a-power-supply. This cable does work, but has the tendency to "overload" many USB chargers, causing them to reset. Fun times, but good for traveling so I don't have to lug the brick around with me as well. image
This "untrusted data" patch series from Benno Lossin is the result of conversations at last weekend's Rust Linux kernel conference in Copenhagen: It's not a "silver bullet" for why we should be using rust in the Linux kernel, but it is a "big giant sledgehammer" to help squash and prevent from happening MANY common types of kernel vulnerabilities and bugs (remember, "all input is evil!" and this change forces you to always be aware of that, which is something that C in the kernel does not.) I had always felt that Rust was the future for what we need to do in Linux, but now I'm sure, because if we can do stuff like this, with no overhead involved (it's all checked at build time), then we would be foolish not to give it a real try. And yes, I've asked for this for years from the C developers, and maybe we can also do it there, but it's not obvious how and no one has come up with a way to do so. Maybe now they will have some more incentive :)