@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.

@aho Others have done research on how long it would take to reimplement code bases based on their size and importance, see that research for details.

In short, it's not going to happen, and no one is asking for it to happen. Just evolve like normally and all will be fine. The Linux kernel you run today has almost no code that was in the kernel you used 25 years ago, so why would it have the same code you use 25 years from now?

Except for the tty layer, that beast is almost identical to what was around in the beginning, and probably will outlive us all...

This "untrusted data" patch series from Benno Lossin is the result of conversations at last weekend's Rust Linux kernel conference in Copenhagen:

https://lore.kernel.org/all/20240913112643.542914-1-benno.lossin@proton.me/

It's not a "silver bullet" for why we should be using rust in the Linux kernel, but it is a "big giant sledgehammer" to help squash and prevent from happening MANY common types of kernel vulnerabilities and bugs (remember, "all input is evil!" and this change forces you to always be aware of that, which is something that C in the kernel does not.)

I had always felt that Rust was the future for what we need to do in Linux, but now I'm sure, because if we can do stuff like this, with no overhead involved (it's all checked at build time), then we would be foolish not to give it a real try.

And yes, I've asked for this for years from the C developers, and maybe we can also do it there, but it's not obvious how and no one has come up with a way to do so. Maybe now they will have some more incentive :)

Must not make a comparison. Really. Must not. But just saying...

Clang Built Linux took literally years of effort. And it's all still C, just a different compiler.

Did anyone really expect Rust for Linux to be a breeze?

I know, I know, apples and oranges.

@sima Right after this happened, I went and checked the LDD3 book, and yes it says this in the chapter about memory:

(internally performed by calling, eventually, __get_free_pages, which is the source of the GFP_ prefix))

So I have no excuse for not remembering this either...

kangrejos in copenhagen was great, but the absolute 🤯 moment was when I learned that GFP_ stands for get_free_pages

I had no idea. and @gregkh next to me had the same https://xkcd.com/1053/ experience

#kernel

@pdp7 @gregkh just out of curiosity I asked ChatGPT what "tip.git" stands for, and it assures me, that it stands for "Tracking Important Patches". Which is on par with LLMs, I guess.

@monsieuricon @pdp7 {sigh} Good news is the machines aren't going to be replacing us any time soon I guess.

BREAKING: Linus rescinds all 'don't break userland' requirements for mm as he deems memory 'virtual' and therefore not real

Anyone else often find themselves starting a retort/reply to a thread here, only to abandon the effort part way through, because you realize your time is better spent supporting/fixing/making things than trying to educate people who haven't bothered to do any of the most basic level of self-education on the given topic?

#selinux