I'm sad to say that we're following the lead of many others and putting in proof-of-work proxies into place to protect ourselves against "AI" crawler bots. Yes, I hate this as much as you, but all other options are currently worse (such as locking us into specific vendors).

We'll be rolling it out on lore.kernel.org and git.kernel.org in the next week or so.

How #Linux Kernel Deals With Tracking CVE #Security Issues: https://thenewstack.io/how-linux-kernel-deals-with-tracking-cve-security-issues/ via @TheNewStack & @sjvn

And why, all too soon, most #opensource projects must also manage their own Common Vulnerabilities and Exposures.

Excellent #keynote by @gregkh at #KubeCon #CloudNativeCon on why we need #Rust in the #Linux kernel, including:

➡️ Standardize, "automate" error handling
➡️ Enforce lock acquisition, automate release
➡️ Type safety

As an important side-effect, switching from C to Rust requires you to ensure APIs fit the cleaner error handling/locking/type paradigms.

To ensure Linux stays secure and maintainers sane.

He also recommended the following 90-minute presentation: https://newsletter.pragmaticengineer.com/p/how-linux-is-built-with-greg-kroah

Many in open source are still unaware of how the Cyber Resilience Act will impact projects and businesses. This blog breaks it down.

Stay informed: https://www.linuxfoundation.org/blog/unaware-and-uncertain-is-the-open-source-community-prepared-for-the-new-regulatory-reality-of-the-cyber-resilience-act

The initial set of speakers and talks for ER is now published. A few highlights:
- @gregkh on the EU Cyber Resiliency Act (CRA)
- barriers to security on embedded systems
- Steam OS impact on Linux ecosystem
- Functional Safety on Linux
- writing real-time applications
- fully open source CNC and 3D printing

and many more: https://embedded-recipes.org/2025/speakers/

Fun, but long, interview with me about how the Linux development process works was just released: https://newsletter.pragmaticengineer.com/p/how-linux-is-built-with-greg-kroah

It's not all boring, I talk about Rust and our lack of project managers (both good things IMO) so there's lots for people to be grumpy about if you are so inclined.

Registration is now open for ER 2025! We hope you can join us this year in Nice, France.
https://embedded-recipes.org/2025/attend/

Perl is now a CNA, able to assign their own CVE ids, this is great news!
https://security.metacpan.org/2025/02/25/cpansec-is-cna-for-perl-and-cpan.html

Just in time for my talk about this very topic in a few weeks about how all open source projects should be doing this:
https://lfms25.sched.com/event/1urXE/take-control-over-your-projects-cve-entries-before-someone-else-does-greg-kroah-hartman-linux-foundation

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

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

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

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

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.