@kernellogger I'll go pick it up for stable/LTS trees now, don't worry :)

For open source people, I recommend reading this fine post from @nlnetlabs / @maarten -> https://blog.nlnetlabs.nl/what-i-learned-in-brussels-the-cyber-resilience-act/ and you might also get some benefit from https://berthub.eu/articles/posts/eu-cra-recitals-comments-compiler-judge/ if you plan on reading the actual act -> https://data.consilium.europa.eu/doc/document/PE-100-2023-INIT/en/pdf 2/2

So… O’Reilly sent me email today hyping up how my books (really, just the one, I assume) is going to be AI-translated into Spanish and German, with other languages to follow. This was probably inevitable, but I still have concerns.

First: are there no human translators of these languages?

Second: who’s going to proof-read all 1,126 pages to make sure nothing got botched, especially given the technical nature of the content? The readers? Which isn’t even crowd-sourcing: it’s customer-sourcing.

@hikari What firmware blobs? The old ones were all in text format anyway (arrays of bytes in a .c or .h file), so that's never really been an issue. I think they are almost all gone from the tree now so that shouldn't be an issue.

For the linux-firmware project, you can send binary diffs to them, in email, git handles that just fine. You aren't reviewing a binary file anyway, it's either you take it or you don't.

@hikari @mcepl @koopa Linux doesn't have binary files in its source tree (for the most part, there are a few tiny exceptions), so this isn't an issue at all.

@hikari @mcepl @koopa Agreed, and for smaller projects, gerrit is almost even nice to use, but for ones with any "real" amount of size of developers and rate of change, it is rough and I curse it every time I have to review a kernel patch series in the Android gerrit instance :)

@hikari @mcepl @koopa "well" is "better than any other web-based workflow" yes, gerrit does handle them better that way.

But no way is it better than an email-based review workflow, whereby I can just tear through hundreds of patches in a very short amount of time, all while sitting behind a very slow/laggy internet connection, or totally disconnected (i.e. better for distraction-free work).

As almost no other project is at the rate of change or size of the Linux kernel, gerrit might be wonderful for your smaller one. But for ones that are our size, realize that centralized workflows like gerrit and the like just do not scale at all.

@ljs @axboe @kernellogger @oleksandr @vbabka That is EXACTLY why AUTOSEL is being used, for subsystems and maintainers and developers who forget to tag their fixes for stable. If everyone was perfect, and all always followed the process without any mistakes, it would not be needed at all.

Also remember that we still have areas of the kernel where subsystem maintainers and developers refuse to add any cc: stable tags, or anything else to give us a hint as to what should be backported, which is why AUTOSEL was created in the first place.

Heck, AUTOSEL catches things _I_ missed for my subsystems and forgot to tag for stable, I want it enabled for my subsystems for that reason alone. A quick glance once a week at what patches I was cc:ed on to verify they were correct is a trivial thing overall.

And as always, if you do NOT want your subsystem to be picked up for either "Fixes:" or AUTOSEL work, just let us know and we will instantly add you to our ignore list as seen here: https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/ignore_list

Every language has an optimization operator. In C++ that operator is //'

Gotta say, if an unknown new printer shows up in my print dialog, my first thought won't be "cool, let's try printing to it."

In systemd we started to do more and more Varlink IPC (instead of or 9n addition to D-Bus), and you might wonder what that is all about. In this AllSystemsGo talk I try to explain things a bit, enjoy: https://media.ccc.de/v/all-systems-go-2024-276-varlink-now-

@brauner from the "rumors" floating around at the last conference I was just at, userspace.

From @gregkh : Rust is going to help us with [CVEs in the Linux Kernel] by eliminating some bug classes.

#RustLang #kr2024

@KernelRecipes So the conclusion from this is that anyone saying "we can't keep up with all the CVEs" is admitting that they can't keep up with all the current (and past!) vulnerabilities present in the kernel.

Either they don't have a threat model, can't triage patches against their threat model, or can't keep up with stable releases due to whatever deployment testing gaps they have.

There are very few deployments I'm aware that can, honestly. This is hardly new, but now it is more visible.

@KernelRecipes Sometimes people need reminding that CVEs are just a stand-in for the real goal: fixing vulnerabilities. The point of "the deployment cannot have any CVEs" isn't an arbitrary check list. The goal is to get as close as possible to "the deployment cannot have any vulnerabilities".

The Linux Kernel CNA solves the "tons of false negatives" problem (but creates the "a few false positives" problem), but the result is a more accurate mapping from vulnerabilities to CVEs.

I'm at Kernel Recipes 2024, starting the live blog now https://kernel-recipes.org/en/2024/category/live-blog/

Day 1 Morning: https://kernel-recipes.org/en/2024/2024/09/18/live-blog-day-1-morning/

#KernelRecipes #kr2024

@xexaxo Thanks for the changes, and the work, much appreciated!

Judging from the absolutely packed out rust sessions I went to at LPC and the very positive support from senior people including especially @gregkh it is super clear to me that rust is here to stay in the kernel and a big part of its future.

Have offered to help (or at least be cc'd in hopes I have time for it :) on mm binding stuff fwiw from the kernel side.

And also I really do have to sit down with rust finally... Maybe advent of code this year...

THIS IS IT!!!

The last hurdle for PREEMPT_RT being merged into mainline has just removed by this pull request. Leaving the door open for PREEMPT_RT to be added to 6.12!

"Defects-in-Depth: Analyzing the Integration of Effective Defenses against One-Day Exploits in Android Kernels" is a great read:
https://www.usenix.org/system/files/usenixsecurity24-maar-defects.pdf

"integrating defense-in-depth mechanisms from the mainline Android kernel could mitigate 84.6% of these exploitation flows"

h/t @rene_mobile
@IAIK