Conversation

It's as if people don't believe me when I say "you must upgrade"...

Quote Tweet

Thorsten Leemhuis – the Linux kernel logger (1/5)

Feb 7, 2021

Today from the tales of "always use really fresh #Linux #kernel versions, as they fix security issues not yet disclosed": * use-after-free in io_uring (fixed in 5.10.2) openwall.com/lists/oss-secu * local priv escalation via futexes (fixed in 5.10.12) openwall.com/lists/oss-secu

198

Replying to

Anyway, patches for security issues should be properly tagged. They're often *hidden* in changelogs these days...

Replying to

And what to do with things that you only realize were "security bugs" after the fact? Like, um, 3 years after the fact (one famous bug fix of mine...)? Why wouldn't you upgrade to fix known bugs be they "security" related or not? What is the downside?

Replying to

and

i mean, one downside is when you have ARM chips that require outdated and heavily modified kernel trees (i.e. literally every Android device) so you can't update and can only backport the security patches you know about :)

Replying to

and

You can definitely apply all the longterm kernel updates and the main issue to deal with is that they've already applied a subset of the changes and backported further changes from mainline. Generic Kernel Images (GKIs) are supposed to be a solution to this part of the problem.

Replying to

Even with GKIs, they still have to actually start shipping the longterm kernel updates reasonably quickly. We used to be promptly applying each longterm release ourselves but it doesn't make much sense for us to be spending our resources on it right now with everything going on.

Replying to

I don't understand how something that a single person can do with a couple days dedicated it to every month is beyond the capabilities of companies like Google and SoC vendors. They need to get rid of the unnecessary per-product/carrier branches/tags and do this important work.

Replying to

It's unrealistic to expect other vendors to do it if even Google isn't doing it for their hardware. I don't actually understand why they aren't doing it. They're way too conservative with updates within release cycles. AOSP would ideally work a lot more like Chromium does...

Replying to

i.e. public beta and dev releases, development in the open and a much quicker time-based release cycles with a far smaller amount of change happening far more frequently. If they did major releases every 6 weeks that had been through 12 weeks of test, I'm sure they'd ship these.

11:47 AM · Feb 19, 2021Twitter Web App

Replying to

Massive yearly release cycles with a huge amount of changes is a broken model. Changes are backed out due to not being entirely ready and get delayed for a year, and other changes are shipped prematurely. It's known to be a bad system. Also makes it harder for forks to keep up.