gregkh

The members of the kernel security team are not allowed to tell their employers anything that happens on the security list. They are there as individual members, not as employees.

And try to define "major distros" in a way that actually means anything viable.

If you just want to count users, then that would only be Android (everything else is a rounding error.) After Android, that would be Yocto, and then Debian. All distros after that are mere fractions of overall users compared to those 3 by number of running systems alone.

If you want to count it as "$ spent on Linux" then that cuts out Android and Yocto and Debian as those distros are free, and would focus purely on the tiny installed base of paid Linux systems, and cut everyone else out.

So what is a fair way to do this other than "we notify no one, and tell everyone to always update their systems to the latest stable releases that we support."

Especially as there is no way for us to determine your use case (i.e. if a specific bug is a vulnerability for you or not.)

They hide structures very easily, allowing programmers to accidentally put them on the stack or use them as parameters in functions where they shouldn't be doing so. By forcing "struct" on the name, it makes it more obvious as to what you are doing.

The amount of resources and other stuff that the LF provides to the Linux kernel community has increased over the years, including last year. Just because new people are brought in with new projects (that the LF member companies want to host) does not mean that somehow less is being given to the kernel community at all. It is not a zero-sum game here at all, that's not how the LF works in any way.

Again, this would have been easy to verify if someone just asked us.

So to repeat, no "abandonment" is happening here at all, the opposite is happening, just like it has for the entirety of the LF's existence, support has grown every year.

Did anyone think to actually ask the developer who is maintaining the LTS kernel versions why he made that change (back in February?), i.e. me?

{sigh}

No, I guess that would take too much effort, and wouldn't result in such a click-bait headline "LTS kernels are no longer supported for 6 years because it turns out no one used them." doesn't have that same fun sound...

No, the only rust code accepted into any released kernels is basic framework infrastructure so that someday, maybe, in the future, real functionality could be written in rust.

There are many out-of-tree examples of rust kernel code, but as of right now, none have been merged.

This already happens today at many companies. I write a few of these a year for companies that I do not work at, and have been for the past decade or so. It's not unusual and the companies that recognize that having their developers be a valued part of the overall kernel community is a very good thing to support.

Corporate guys "manage me"? Have you talked to any corporate guys who have actually tried that and discussed the results with them? :)

Yes, and because of that, we created a new process for those types of issues (i.e. broken hardware problems that need more coordination.) That process is documented at https://www.kernel.org/doc/html/latest/process/embargoed-har... if you are curious.

It's been working semi-well, and gives us a way to deal with longer embargo times (like months instead of weeks and days), but it does not integrate well into the linux-distro-like way of working just yet, which is an issue that hopefully will be resolved sometime in the future if the linux-distro members wish it to be.

I've described how we (the kernel security team) handles this type of things many times, and even summarized it in the past here: http://www.kroah.com/log/blog/2018/02/05/linux-kernel-releas... Scroll down to the section entitled "Security" for the details.

If you wish to disagree with how we handle all of this, wonderful, we will be glad to discuss it on the mailing lists. Just don't try to rehash all the same old arguments again, as that's not going to work at all.

Also, this was fixed in a public kernel last week, what prevented you from updating your kernel already? Did you need more time to test the last release?

Edit: It was fixed in a public release 12 days ago.

While I did drop by a lot, you aren't describing me, but rather another Linux kernel developer who worked at IBM in our group at the time who is by far more brilliant and smarter than I.

I've never smoked, and at that point in time, I did not have long hair anymore (cut it off when I turned 30 which was before OSDL was ever started.)

I'm not understanding the question here at all, sorry, can you please rephrase it?

And if you have questions about how this happened, look at the source for when it was merged, it's all there for everyone to review :)

Also, udevd is a program, not a library.

The person who started udev (i.e. me), and the person who did the majority of the work on udev to make it into the proper solution for everyone (i.e. Kay Sievers), both agreed that it made more sense to move it into the systemd codebase in order for lots of duplicated code and functionality to be removed.

By doing this, we have made the maintenance and support for this core userspace tool much easier for everyone who was involved in working on it.

If the developers involved in a project do not do what you want with that project, feel free to fork the project as that's the beauty of open source! And hey, that's exactly what the eudev developers did, go use their fork if you want to, no one is forcing you to use the version from systemd, just like no one is forcing you to use any other open source program. It's your choice to do so or not :)

Off the top of my head, no.

The big "downside" is that it takes more work on the patch submitter side. But the benefits in the end are almost always more than worth it (easier reviewer time, easier time to track down problems, better development cycle as feedback can be more specific, easier evolution of changes, etc.)

I wrote a whole chapter in the book "Beautiful Code" about how this development model can help create an end result that is almost always better than the initial "huge" submission model. Check it out if you are interested, it should be free online somewhere...

Merge the portions that you know are correct and will have no affect on anyone else now, which makes future work easier as you do not have to keep those "working" commits up to date.

We do this all the time with kernel development, and is one reason why breaking changes up into tiny pieces is so powerful. We can take the pieces that make sense now, and allow the developer to redo the portions that are not ready yet, instead of having to reject the whole thing if it were done in one single "chunk."

Also note that the TTY/serial portions of this hardware support was already merged through the serial tree because they were independent and didn't affect anyone else.

Thanks for the support.

I also now have submitted a patch series that reverts the majority of all of their contributions so that we can go and properly review them at a later point in time: https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh...

Why is it "excessive"? We are running 30+ fixes a day in these kernel releases, who would benefit if we delayed in getting those known-bug/security fixes out to the world quickly and properly tested (as we are currently doing)?

Why wait? What is a slower cadence going to accomplish?

So you want us to just stop fixing bugs and pushing out those fixes to users? That feels risky, if you do not want to upgrade to solve known problems, that's fine, feel free to skip upgrades. But why would you want to prevent those who want to run secure systems that ability?

Time to get a new ISP? :)

And what would that help solve?

We have so many different CI systems running on the kernel on a hourly basis.

We have the 0-day bot from Intel that runs so many things on all developer trees. We have kernelci running on many many different hardware platforms, and we have Linaro test systems also running on many different branches and hardware platforms.

If you want to tie your own hardware into the system, kernelci is the best place to start, I recommend looking into that.

thanks!

Simplest thing to do, just run Linus's latest releases (the -rc releases), or from his git tree, on your machine and report any problem.

Second-simplest thing to do is to run the linux-next branch/tree on your machines and report any build warnings and runtime issues you find. That's what will be the "next" kernel releases and is where all of the developer/maintainer trees are merged together before they are sent to Linus.

Both of those should be very easy to do, and any problems found there should be easy to fix and resolve before they get to a "real" release.

If people don't report bugs, we don't know they are there as it "works for me!".

This isn't "negativity", this is people not understanding how the process works :)

And you're welcome!

Where in the current CI that we have today is lacking that needs to be improved? We always want more testing and testers, what is preventing everyone from helping with this?

I get a vacation? Hah!

Everyone gets older, the alternative isn't as attractive :)

Seriously, the kernel averages about 200-250 new contributors every release (i.e. every 2 1/2 months). We are not starved for new contributors at the moment at all, do you think we are somehow not attracting new developers compared to other open source projects?

"regular stable kernel" lives only about 3-4 months, just long enough for the next release from Linus to feel "good enough".

"longterm kernel" lives for 2+ years. I pick one each year (usually the last one released in a year) for that.

See the releases page on kernel.org for details on what the longterm kernels are, and for how long they are being maintained and by whom.

That "partially-ABI stable" is the same exact thing that Red Hat and SUSE and Debian have been doing for 20+ years now. Nothing major and exciting there, but see the presentations at the Linux Plumbers conferences for details on the tools being used if people are curious (hint this time everyone is working together on the same set of tools...)

And what would that "middle ground" look like?

With the current rate of change that the kernel community develops at, including the patches backported to the stable/longterm kernels, it's impossible to try to evaluate each and every patch for "is this something that could be exploited or not?"

Companies have tried, it was fun watching them, but they quickly gave up and declared it impossible and much safer to just take all stable patch updates instead.

I've also talked to MITRE about just applying for a CVE for ever stable kernel patch (20+ a day), and while they appreciated me not doing that, they agreed that the current model of CVEs just does not work at all for the Linux kernel and that what we are doing is fine.

See my Kernel Recipes talk last year for details about all of that if you are curious.

Android doesn't seem to mind, they require the LTS updates to be taken for their devices (well, "require" is a strong word, they are pushing harder now than they were in the past, "required" will be happening in the future, hopefully...)

As the number of systems running RHEL is really just a rounding error compared to the number of Android systems out there, maybe it doesn't really matter :)

They feel like they know better and do not want all of the fixes that the LTS kernels provide for some crazy reason.

I suggest you contact them if you rely on a RHEL kernel to ask them why they do this, it's always seemed crazy.

Note, I'm the person who does the LTS kernel releases, maybe they just don't like me :)