At least once a day I'm reminded of this slide from @bagder last year at FOSDEM

@hughsie What about the real CVE github repo at https://github.com/CVEProject/cvelistV5.git ? Never trust the "additions" that NVD adds to cve records, they are often totally incorrect in odd ways. Stick to the raw records please.

Having all CVEs in one git repo makes it easy to use 'git grep' to search.

What comes after world domination?

This is the abstract for my scheduled talk at foss-north 2025 in April. What do you think is next?

https://foss-north.se/2025/

Where's all the commentary and speculation for good kernel rust stories? https://www.phoronix.com/news/Linux-6.14-Faux-Bus-Merged

@jani Yes it does! Look at this patch that handles that case explicitly: https://lore.kernel.org/all/2025021027-stove-dolly-9aed@gregkh/

While I don't know if is the first time this has happened, it's good to acknowledge this given all the crazy, odd, and incorrect press about Rust in Linux these days.

A new in-kernel api just landed in linux-next from my tree and should hopefully show up in 6.14 to make some kinds of drivers easier to write, that has a rust binding added at the exact same time:
https://lore.kernel.org/all/2025021023-sandstorm-precise-9f5d@gregkh/

Many thanks to Lyude and Danilo and many other Rust kernel developers for the help in creating the binding and make the C side work well for both Rust and C code at the same time. The end result here for any C developer alone, is much better off for all of their help.

how to change the kernel[1]

1. assemble a sufficient coalition of willing fools
2. do it
3. if it works, ask for forgiveness, if it fails, quietly bury it and try the next thing

the more public success you pile up, the easier this gets. but if you fail at step 1, because your ego gets in the way, or you lack the political skills, or you think talking about anything non-technical is verboten, it will be endless amounts of pain and frustration

1: anything you want to change really

#kernel

https://www.linuxfoundation.org/blog/navigating-global-regulations-and-open-source-us-ofac-sanctions

TL;DR: Maintainers can accept patches from sanctioned entities, but not request more details, or suggest changes for a v2...

For 2025, here is a updated and hopefully-useful notice about Linux kernel security issues, as it seems like this knowledge isn't distributed very widely based on the number of emails I still get on a weekly basis:

- The Linux kernel security team does not have any "early notice" announcement list for security fixes for anyone, as that would only make things more insecure for everyone. The number of organizations that fail to understand this is way too high.

- The kernel community DOES assign CVEs, as we are a CNA, please see https://www.kernel.org/doc/html/latest/process/cve.html for how they are handled and assigned. Side note, we were #2 in quantity for CVE assignments in 2024 despite only doing so for 10 1/2 months, averaging about 10 CVEs per day. Any process you might have where you feel you need to research each CVE on an individual basis manually is going to be a major time suck, automate it! All CVE entries are provided with proper git commit ids for the vulnerable release ranges for you to check yourself, AND we have tools and other formats that you can use to check this yourself. See https://git.kernel.org/pub/scm/linux/security/vulns.git/ for the tools and raw data for you to pull from directly if you don't want to deal with the cve.org json feed.

- Kernel CVE entries are constantly updated over time, you can not just look a them only when created, and then ignore all updates. Too many groups are missing revoked CVE entries and tightening of vulnerable kernel ranges that we are updating on a weekly basis. By ignoring the updates, you are causing yourself more work, not less. cve.org provides an "updated" feed in their git tree, use it!

- Along the lines of the huge number of recorded CVEs, you HAVE to take all of the stable/LTS releases in order to have a
secure and stable system. If you attempt to cherry-pick random patches you will NOT fix all of the known, and unknown, problems,
but rather you will end up with a potentially more insecure system, and one that contains known bugs. Reliance on an "enterprise"
distribution to provide this for your systems is up to you, discuss it with them as to how they achieve this result as this is what you are paying for. If you aren't paying for it, just use Debian, they know what they are doing and track the stable kernels and have a larger installed base than any other Linux distro. For embedded, use Yocto, they track the stable releases, or keep your own buildroot-based system up to date with the new releases.

- Test all stable/LTS releases on your workload and hardware before putting the kernel into "production" as everyone runs a different %
of the kernel source code from everyone else (servers run about 1.5mil lines of code, embedded runs about 3.5mil lines of code, your mileage will vary). If you can't test releases before moving them into production, you might want to solve that problem first.

- A fix for a known bug is better than the potential of a fix causing a future problem as future problems, when found, will be fixed then.

Good summary for what all developers should know about about sanction laws and software development in a global environment,

https://www.linuxfoundation.org/blog/navigating-global-regulations-and-open-source-us-ofac-sanctions

@danderson Fuchsia was described to me by its lead as "Plan 9 without files", which is as comprehensible to me as "biology without life". In fairness, that expressed more of a lack of understanding of Plan 9 than a bizarre architecture. I wish it had done well, but that figure you quote worries me.

It’s been a long time coming... and it's finally here!

We’re making all the resources from Kernel Recipes available to you, from the very start (yep, there are some gems in there!). It’s still a little rough around the edges in terms of interface, but it’s totally usable: slides, videos, photos, and drawings

Plus, don’t worry – we’re keeping last year’s site online, and the current one too. So, dive in and start exploring!

Enjoy! 🚀

https://archives.kernel-recipes.org/

I am so amused by the whining from the data scraping tech bros about (GASP) the data scraping being done by other people...
https://www.404media.co/openai-furious-deepseek-might-have-stolen-all-the-data-openai-stole-from-us/

Of course we'll go from vilification, to banning, to public subsidy of the domestic tech bros in order to protect our "lead" in... whatever it is that the current type of garbage GenAI is good for.

Oh, wait, we already jumped to the last part

🥳 "'We are almost at the "write a real driver in #rust" stage now, depending on what you want to do."' 🥳

That's what @gregkh wrote in the comment for the main driver core and debugfs updates merged for #Linux 6.14, as it contained "driver core rust bindings for PCI, platform, OF, and some i/o functions"; there is also a "misc device rust bindings and a sample driver to show how to use them":

https://git.kernel.org/torvalds/c/2ab002c755bfa88777e3f2db884d531f3010736c

#LinuxKernel #kernel #rustlang

@bagder Oh crap, yes, that does work on this model! It's even buried on the spec sheet if you read it close enough. It didn't on a previous model I had, so I'll blame that reason why I never tried this out. Ok, one less cable to carry around with me when traveling now, thanks!

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.

I presented at Everything Open @everythingopen this afternoon. 🗣️🐧

My slides are already available for anyone who'd like to check them out.

Thanks for having me - I really enjoyed the session! 🙂 ✌🏽

https://embeddedor.com/slides/2025/eo/eo2025.pdf

@alwayscurious @sima @sourcejedi That's one reason, the other one was "power just glitched, my printer better be on the same device node it was before it was turned off". Same for keyboards, mice, disks, etc.

@alwayscurious @sima "Normal" PCI hotplug systems should export this information, as the BIOS expects a user to add/remove PCI devices on a slot basis. Otherwise why would a BIOS care about exporting the slot number at all. So it's not required, and you are lucky if it shows up. good luck!

@joshbressers Linux is only #6? We better get on that to reclaim our 2nd ranked spot of last year despite only participating for 10 1/2 months, not the full 12 everyone else was able to have! :)