Notices by Thorsten Leemhuis (acct. 1/4) (kernellogger@fosstodon.org), page 3

2/ Linus in a reply to the #Linux 6.11-rc5 announcement

"'Oh, and I forgot to mention that there's something special about this Sunday: today, Aug 25th, is the 33th anniversary of the original public mention of Linux […]

and while 33 years may not sound like a particularly round number, the "brewing since April" means that it was actually 33 and 1/3 years ago that it all started.

A third of a century. And it *still* isn't ready. I really need to get my sh*t together.."'

#kernel #LinuxKernel

#Linux 6.11-rc5 is out: about half a day earlier than usual because Linus is travelling.

https://lore.kernel.org/lkml/CAHk-=wh599movdAyCHfVmYakq8rqKQD9wCvUAgBqbF3znEu_2g@mail.gmail.com/

"'Other than the timing, there's not a whole lot unusual here. […]

So please do go forth and test, it all looks safe,

Linus "famous last words" Torvalds'"

#kernel #LinuxKernel

Note to self: do not buy any #HP #Omen any time soon for #Linux use:

"[…] I *DO* have to warn you that fan control for both the GPU and the CPU is done solely and passively by the embedded controller, and not the #kernel -- and that is problematic.

On my laptop (8BAD), it is pretty clear that the provided/passive fan curve table is broken. The fans run slower than what they should be, which results in potential overheating UNLESS […]"

https://bugzilla.kernel.org/show_bug.cgi?id=219125#c1 #LinuxKernel #Laptop

#Linux #kernel and #XFS developer Darrick Wong writes:

"'XFS now has self healing capabilities! In the near future, that will become autonomous self healing capabilities.

Online repair will be fully merged in Linux 6.10 and xfsprogs 6.10, which means that the kernel can rebuild all space management and directory tree metadata while the filesystem continues to run. The ability to detect and correct inconsistencies […']"

https://blogs.oracle.com/linux/post/xfs-online-filesystem-repair #LinuxKernel

Jeremy Allison writes:

'" The data shows that “frozen” vendor #Linux kernels, created by branching off a release point and then using a team of engineers to select specific patches to back-port to that branch, are buggier than the upstream “stable” Linux #kernel created by Greg Kroah-Hartman. '"

https://ciq.com/blog/why-a-frozen-linux-kernel-isnt-the-safest-choice-for-security/ #LinuxKernel

The Kernel Report - Jonathan Corbet (@corbet), @LWN

The recording of this recent talk is now available on the #ossna2024 schedule page: https://ossna2024.sched.com/event/1aBNs/the-kernel-report-jonathan-corbet-lwnnet

Slides can be found here: https://static.lwn.net/talks/2024/kr-ossna.pdf

Direct link to the recording: https://www.youtube.com/watch?v=DAqjl_x4hZc

#Linux #kernel #LinuxKernel

@Suiseiseki

sure, but that's considered Firmware and executed on the GPU – one might like it or not, but it avoids the prop. driver problem on the OS kernel level

@ariadne did Ubuntu switch from the proprietary to the open module already?

And if they did: did they do so everywhere (including for legecy drivers and old Ubuntu releases)? I doubt that, so they likely still are considered a problem.

Lasse Collin's patch-series updating the #LinuxKernel's #xz code that a few days ago hit #linux-next was dropped for now until backdooring of upstream xz is understood better:

https://lore.kernel.org/all/20240329195602.382cb1c99bb70e3d8c6093ae@linux-foundation.org/

Lasse Collin, original author of #Xz, replied on #LKML: https://lore.kernel.org/lkml/20240330144848.102a1e8c@kaneli/

"'"[…] I'm on a holiday and only happened to look at my emails and it seems to be a major mess.

My proper investigation efforts likely start in the first days of April. That is, I currently know only a few facts which alone are bad enough.

Info will be updated here: https://tukaani.org/xz-backdoor/"'"

#CVE20243094 #Linux #kernel #LinuxKernel #Backdoor

Karel Zak released util-linux v2.40:

https://lore.kernel.org/all/20240327151052.5kjyfcy5w7wnkqf3@ws.net.home/

For a list of new features, see also his blog post from two months ago:

http://karelzak.blogspot.com/2024/01/whats-new-in-util-linux-v240.html

"'"welcome lsclocks, a new util-linux command. […]

dmesg(1) parses caller-id from kernel messages and prints it.

The new small command "exch" can atomically exchange paths between two files.

Applications can utilize the filter before gathering all data for output, reducing resource usage and improving performance. […]"'"

#Linux

@ljs

And wrt to "It strikes me as quite naive [...]": maybe, but it's a bit like better docs, regression tracking and some other unattractive work in kernel land: a lot of people want those things to be better, but its hard to find the money to pay people to do all that work.

@ljs

don't worry, I will speak up when I see the need; but reg. the CVE stuff and a lot of the critique wrt to how the stable team operates I seem to be somewhat in line with Greg's approach *or* think the problems need to be fixed elsewhere to improve things (the latter is on my todo list).

And 'company line'? Come on, this is the kernel community, there is no company line, just individuals with a lot of different options 😇

/me runs 😬

"[…] It is clear that the current process is based on the learnings, and frustrations, the [#Linux #kernel's CVE] team has faced in the past. […] By taking this position, this effort is now duplicated across thousands of engineering teams ad infinitum, […]"

Well, yeah, but guess what: maybe then the companies behind those engineering teams will join up and invest money to handle the problem "[…] at the source, in a central, efficient and reliable manner. […]". 😬

https://amanitasecurity.com/posts/dear-linux-kernel-cna-what-have-you-done/

Really glad that @gregkh refuses[1] to pick up changes for stable/longterm #Linux series (say 5.4.y), if they have not yet been applied to all newer series (e.g. 5.10.y, 5.15.y, …). This is crucial, as people otherwise would run into #regressions if they'd sooner or later update from the older to one of the newer series.

[1] every few weeks (or even more often) some developer learns that aspect through a mail like https://lore.kernel.org/all/2024022603-speculate-staple-4f54@gregkh/

#kernel #LinuxKernel

Did a quick *rough* check:

* 65 #Linux #kernel CVE announcements from Greg so far

* 55 of those refer to a mainline commit

* 10 of those were marked for backporting to stable/longterm

And that's why Greg backports a lot of #LinuxKernel mainline commits to stable/longterm that are *not* tagged for backporting -- and why "only backport changes mainline developers[1] tagged for backporting" is a bad idea.

[1] reminder, such tagging is optional, as participation in stable/longterm is optional

@gregkh

Will be interesting to see how the new process[1] plays together with "participation in stable is optional for mainline developers" and the "developers almost never declare specific changes as security fixes"[2] approach I assume still holds true for mainline.

I sounds like it could easily happen that someone fixes a security bug in mainline w/o telling anybody, so no CVE would be issued unless someone backports the change.

[1] https://lore.kernel.org/lkml/2024021314-unwelcome-shrill-690e@gregkh/

[2] http://kroah.com/log/blog/2018/02/05/linux-kernel-release-model/#security

@gregkh

Will also be interesting to see how many CVE will be issued it the end; it sounds like it will be a whole lot, which likely will have some interesting effects. 😬

Just published "Regression tracking: state of the union early 2024": https://linux-regtracking.leemhuis.info/post/status-jan2024/

"'"I'm not really happy with my performance wrt to my #regression tracking efforts during the last year. To counter that, I've already shifted my focus somewhat ~in October. With the new year I will shift it some more. Top-priority will be "make #regzbot more useful for kernel subsystem maintainers" from now on. My tracking efforts of course will continue, […]"'"

#Linux #kernel #LinuxKernel

"'"[…] #eBPF programs are compiled down to eBPF bytecode and attached to hooks in the kernel via a syscall. This is tedious; so many libraries for eBPF allow you to write applications using and interacting with eBPF in C++, Rust, Go, Python, and even Lua.

But there are none for #Java, which is a pity. So… I decided to write bindings using the new Foreign Function API (Project Panama, preview in 21) and #bcc […]"'"

https://mostlynerdless.de/blog/2023/12/31/hello-ebpf-developing-ebpf-apps-in-java-1/ #Linux #kernel #BPF #LinuxKernel