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/

@rpardini @torvalds Yup, is there now, sorry for the delay.

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/

@AugierLe42e Hopefully yes, but it depends on the firmware on the hub itself, it's not under control of the operating system at all.

@AugierLe42e Look at how the "port" is found when you do something like 'lsusb -t', I think that should help out here. Good luck!

@sjn @cpansec Thanks for the clarification, and yes, I will mention it!

@bagder As Red Hat just became a root at the same time Perl became a CNA, odds are that wasn't an option yet. But yes, going forward I think having most/many open source groups be under Red Hat is a good option to help reduce the load on MITRE.

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

@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