@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

I presented at Open Source Summit Europe this afternoon. 🗣️🐧

My slides are already available if anyone wants to check them out. My audience was great, and it seems they enjoyed the talk. 😃

Now, I'll be focusing on Linux Plumbers.

https://embeddedor.com/slides/2024/lceu/lceu2024.pdf (pdf)

#Linux 6.11 is out:

https://lore.kernel.org/lkml/CAHk-=whVpSHw9+4ov=oLevfv8sPYbh59T_9VKif-6Vqkr41jQA@mail.gmail.com/

'"I'm once again on the road and not in my normal timezone, but it's Sunday afternoon here in Vienna, and 6.11 is out.

The last week was actually pretty quiet and calm, which is nice to see. […]

Anyway, with this, the merge window will obviously open tomorrow, and I already have 40+ pull requests pending. That said, exactly _because_ I'm on the road, it will probably be a fairly slow start […] please be patient."'

#Kernel #LinuxKernel

@uis oooh, nice, and the documentation for it says it is for something like "a system call in an operating system". Odd, who added it to the compiler and why didn't they talk to any kernel developers about it if this feature is supposed to be for us?

Is there a different operating system out there that uses newer versions of gcc as their primary compiler that is using this?

That being said, it's a good start, and will require us to use -fanalyzer which I think people are working toward, so maybe there is hope!

In the same topic of "use frameworks to make bugs very hard to create", Alice Ryhl's patches for using a "range" api to access data from userspace:

https://lore.kernel.org/r/20240913210031.20802-1-aliceryhl@google.com

along with examples of how recent binder bugs were affected by this issue in C, and also were present in the Rust implementation, along with a proposal for how to prevent that are another good example of how the language can help us in kernel land by creating apis to help us do the right thing.