If you enjoy the hairiest of bug hunts with a thrilling conclusion, this one is for you. The hunt and hair pulling:

https://lore.kernel.org/regressions/480932026.45576726.1699374859845.JavaMail.zimbra@raptorengineeringinc.com/

and the conclusion:

https://lore.kernel.org/regressions/1105090647.48374193.1700351103830.JavaMail.zimbra@raptorengineeringinc.com/

Hats off to Timothy for seeing this one through to completion!

So, you want to read LKML with Gmail (experimental, testers needed)

https://lore.kernel.org/workflows/20231115-black-partridge-of-growth-54bf2e@nitro/

So many truths are hidden,
So many facts untold,
Queries left unbidden,
Concealed below the fold.

My head droops to the table,
But I must remain informed:
"Is the kernel stable?"
"How is babby formed?"

RFC for the replacing the Linux kernel #Android #Binder driver with a fully functional #Rust version:

https://lore.kernel.org/lkml/20231101-rust-binder-v1-0-08ba9197f637@google.com/

All the talks from Embedded Recipes 2023 are now online, including "The TTY Layer: the Past, Present, and Future" by @gregkh https://www.youtube.com/watch?v=g4sZUBS57OQ&list=PLwnbCeeZfQ_Mi7gjUpLZxXGOcEBS_K8kH&index=5 #er2023

This came up in a private thread about a kernel patch review where the contents were created with an "AI" tool, so I figured I might as well put it somewhere a bit more public as people don't seem to really understand the issues involved:

My policy is that I do not take any output of any "AI" tools unless the providence of the data that was used to feed the AI tool can be proven to be under the proper copyright rules as to be compatible with the GPLv2 license.

So in other words, nothing from chatgpt at all, that's obviously full of copyrighted works that are not allowed to be reused in this manner.

#Linux #kernel 6.6 is out: https://lore.kernel.org/all/CAHk-=wiZuU984NWVgP4snp8sEt4Ux5Mp_pxAN5MNV9VpcGUo+A@mail.gmail.com/

"""So this last week has been pretty calm, and I have absolutely no excuses to delay the v6.6 release any more, so here it is. […] Linus"""

For an overview of new features, check out the two #LinuxKernel 6.6 merge window articles from @LWN or the Kernelnewbies summary:

https://lwn.net/Articles/942954/ and https://lwn.net/Articles/943245/

https://kernelnewbies.org/Linux_6.6

Not a tragedy: "The greatest value that #opensource foundations bring is the creation of a neutral collaboration hub for everyone participating in, and taking a dependency on, a project."

https://www.linuxfoundation.org/blog/how-open-source-foundations-protect-the-licensing-integrity-of-open-source-projects

https://www.centerforcybersecuritypolicy.org/insights-and-research/joint-letter-of-experts-on-cra-and-vulnerability-disclosure A good letter to the EU governments about why the CRA isn't going to be good for vulnerability disclosure as-written. It's nice to see this portion of the CRA finally getting some exposure.

TIL there is an ISO standard for security vulnerability disclosure. First version was made final in 2014, latest version in 2018. Despite actually working in this area for 20+ years, I only now hear of this, yet can't actually see it due to crazy ISO document rules {sigh}
https://www.iso.org/standard/72311.html

So I presented today on EU CRA, NIS2 and other initiatives to regulate code/hardware/services. One consistent piece of feedback I got is that the amount of upcoming regulation is so huge that even dedicated professionals are unable to keep track of it all. So it is not just me (or you). It is _a lot_. https://berthub.eu/one/EU%20and%20you.pdf

How to fix the TTY layer in Linux?
@gregkh explains at #er2023
https://git.sr.ht/~gregkh/presentation-tty/tree/9afefcf3171a02e5eee19639ec62456511902a56/item/tty.pdf

Slides and recording of @gregkh's great @KernelRecipes talk "#Linux #Kernel security demistified" are now online:

Slides: https://git.sr.ht/~gregkh/presentation-security/blob/3547183843399d693c35b502cf4a313e256d0dd8/security-stuff.pdf

Video: https://www.youtube.com/watch?v=xDHTn0auo2w&t=14975s (that's a section of the live stream) #LinuxKernel

Slides for my @KernelRecipes talk from yesterday for "Linux Kernel security demistified" can be found here: https://git.sr.ht/~gregkh/presentation-security and the video will be probably online sometime "soon" for those that missed the live stream.

@davem_dokebi our godfather on stage for a sump up of netconf 2023 #kr2023

A sign of DisplayPort over USB-C (external display) working with the #mainline kernel on the recently launched #Fairphone 5!

This wouldn't have been possible without the great work done by all the people contributing to Linux and this SoC, especially the amazing people at Linaro!

#postmarketOS #Fairphone5 #LinuxMobile #kr2023 #KernelRecipes

@gregkh on stage: Demystifying the Linux kernel security process #kr2023 - serious things coming...

So OSS Europe was an interesting experience, this year, in a way.

I did my usual talk, and started with the usual section on kernel releases. When talking about stable updates I tossed in a quick mention that six-year support from the stable team was being phased out — something I understood to be generally known for about the last year. Way at the end of the talk, as my last topic, I discussed at some length the stresses being felt by kernel maintainers.

@sjvn wrote an article about the talk (https://www.zdnet.com/article/long-term-support-for-linux-kernel-to-be-cut-as-maintainence-remains-under-strain/) and made a connection between the stable-policy change and the maintainer issue — something I had not done in the talk. It was a bit of a shift from what I said, but not a bad article overall.

Then the rest of the net filled up with other writers putting up articles that were clearly just cribbed from SJVN's piece — sometimes with credit, sometimes without. I'm getting emails about what a terrible idea this all is, as if I had anything to do with that decision or can somehow change it. I have, it seems, taken away everybody's six-year support, and they're not happy about it.

All because of a 30-second mention of a change that was made public something like a year ago. My 1.5 minutes of fame has given me a new appreciation for this old quote from Rusty Russell: "when a respected information source covers something where you have on-the-ground experience, the result is often to make you wonder how much fecal matter you've swallowed in areas outside your own expertise."

Here is a 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 get on a weekly basis:

- The 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 kernel community does not assign CVEs, nor do we deal with them
at all. This is documented in the kernel's security policy, yet we
still have a number of people asking for CVE numbers even after
reading that policy. See my longer "CVEs are dead..." talk for full
details about how the CVE process is broken for projects like Linux:
https://kernel-recipes.org/en/2019/talks/cves-are-dead-long-live-the-cve/

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

I think I need to give another talk about this issue to go into the above in more detail. So much for me giving a technical talk at Kernel Recipes this year...

When your server is doing too many builds at once...