Slashdot Mirror
Linus Finally Releases Linux 4.15 Kernel, Blames Intel For Delay (phoronix.com)
An anonymous reader writes: Linus Torvalds has released Linux 4.15 following the lengthy development cycle due to the Spectre v2 and Meltdown CPU vulnerability mitigation work. This update comes with many kernel improvements including RISC-V architecture support, AMDGPU Display Code support, Intel Coffee Lake graphics support, and many other improvements.
"This obviously was not a pleasant release cycle, with the whole meltdown/spectre thing coming in in the middle of the cycle and not really gelling with our normal release cycle," Linus writes. "The extra two weeks were obviously mainly due to that whole timing issue... [T]he news cycle notwithstanding, the bulk of the 4.15 work is all the regular plodding 'boring' stuff. And I mean that in the best possible way. It may not be glamorous and get the headlines, but it's the bread and butter of kernel development, and is in many ways the really important stuff.
"Go forth and play with it, things actually look pretty good despite everything. And obviously this also means that the merge window for 4.16 is open... Hopefully we'll have a _normal_ and entirely boring release cycle for 4.16. Because boring really is good."
"This obviously was not a pleasant release cycle, with the whole meltdown/spectre thing coming in in the middle of the cycle and not really gelling with our normal release cycle," Linus writes. "The extra two weeks were obviously mainly due to that whole timing issue... [T]he news cycle notwithstanding, the bulk of the 4.15 work is all the regular plodding 'boring' stuff. And I mean that in the best possible way. It may not be glamorous and get the headlines, but it's the bread and butter of kernel development, and is in many ways the really important stuff.
"Go forth and play with it, things actually look pretty good despite everything. And obviously this also means that the merge window for 4.16 is open... Hopefully we'll have a _normal_ and entirely boring release cycle for 4.16. Because boring really is good."
... intel.
It little behooves the best of us to comment on the rest of us.
He blames the Meltdown/Spectre mess in general (duh!), but he only blames the timing, which is either the discoverer's fault, or Microsoft's: the embargo was timed to coincide with patch Tuesday.
While the root cause may be placed at Intel's door, the timing of the disclosure after 10+ years of vulnerability is hardly Intel's choice, and Linus (correctly) refrains from linking them to it in any way.
Stop with the whiny editorializing in the headlines. Headlines are for facts, not for your opinion about how long it should take people who do real work to do it.
Servers
Headlines are for creating an emotional reaction in people to make them more likely to click on the article to read and/or comment. Guess who it worked on?
3% on the desktop last year, estimated to be 5% this year. As for the server market, 79% as of 2014 and has risen every year since. Plus all your little gadgets around the house: routers, modems, phones, TV's, set-top-boxes, IoT devices. Linux is everywhere, you could almost guarantee that there's a Linux powered device in your house and you might not know about it. And as the Kernel makes them tick, changes to it are important.
systemd is not a part of the kernel. I'm giving you the benefit of the doubt here, assuming that you didn't realize that. If you don't like systemd and want to use Linux there are various options that I've considered, but not tried. There's Devuan, Slackware, etc., i.e. various distributions that don't use it at all. Or, if you want, you can customize a Debian or Gentoo installation to not use systemd. I'm not sure how long that will be possible, but it is for now.
There are also things like blackbox Linux or Linux from Scratch with allow you to assemble a system with only those pieces you desire.
That said, there are also arguments in favor of various of the BSDs. I would probably have tried them out over systemd if they could handle read/write of ext4 filesystems. There are systems I could use as an intermediate if I felt strongly enough, but systemd may not have given me any advantages, but the problems haven't been very significant, so I've never bothered.
And if you're a troll, at least this was a place to reasonably inform anyone who trusted you.
I think we've pushed this "anyone can grow up to be president" thing too far.
Today in Linux, tomorrow in Android
I agree that kernel changes are important, but this article is really light on what those changes are. A name doesn't tell you much unless you already know what that name stands for. I can't tell whether I have any reason to care about this update or not.
In fact, I'm rather annoyed by the way kernel changes reporting is done. Most articles that even pretend to be instructive pass you a link to a change log as if it were an explanation. I'm not a kernel hacker, and I don't really want to be one. I've got other things on my plate. So usually I just end up assuming that whatever the changes are they won't make any difference to me. This time there was the mention of certain specific drivers being included, and those don't matter to me. But at least that was intelligible. I'm guessing that this kernel DOESN'T include the Spectre fix, but that's a guess. (An earlier version apparently included it as a default choice with optional disabling...unless that was Meltdown.)
So I consider kernel news important, but done so poorly as to be annoyingly confusing.
I think we've pushed this "anyone can grow up to be president" thing too far.
Which notably is where both meltdown and spectre actually look really scary. Because that's the land of "compromising one specific machine can cost you a massive amount of effort, because it's still profitable".
Userland, there's actually very little worrying. There's very little value in reading random memory of any single end user machine one chunk at a time when there's nothing else you can really do. There just isn't anything that is all that valuable on such a machine to justify the effort, much less make a profit out of it.
I thought everyone in the super-fun-secret club knew about Spectre and Meltdown like 6 months ago, because it took them time to code up fixes? I'm guessing Linux kernel devs weren't part of the super-fun-secret club?
In general, Linux devs happens to have been working for a general class of technology (KAISER, now KPTI) that happens to also be useful against Meltdown (in addition to tons of other problems).
So from the perspective of Linux devs, not much changed (and it is the general mantra in team Linus Torvalds, that *any* bugs is a serious bug, no matter if it is a security one or not - so it's a general tendency that when there are security reports, it's business as usual).
The problem comes from the answer of the manufacturers :
- intel botched patches they were submitting (see Linus' ire about them), intel provided buggy firmware (CPU microcode) that causes problems and that Dell and HP ended-up delaying. Intel has tried to enable Meltdown circumvention for everyone even if they're almost the only constructor that's concerned, etc.
- AMD still can't really decide if version 2 of Spectre (abusing the indiredct branch prediction) can actually lead to an actual usable exploit in the wild or not. Though they at least now have determined that a few of their CPUs (since Zen, I think) are affected. So at least for now it's "enable retpoline for them, too".
etc.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Currently no protection, but also no danger - the actual exploits still don't exist, and aren't expected to show up anytime soon (the vulnerabilities are damn obscure and difficult to exploit) - plus one thing to notice the exploit in action would be a massive CPU load spike - the proof-of-concept programs were extremely CPU-heavy.
Thing is currently there are counter-measures in place that change the old exploit approach of "just call a fixed address" into "map the entire memory and locate the address you need to call" - randomization of code locations meaning the exploits need to *find* given data in restricted memory instead of just picking it from a known location through (illegally) elevated privileges.
And both Spectre and Meltdown have an abysmally low data leak rate - something like 1 bit per 200 microseconds. Mapping the couple gigabytes in order to find the usable data/procedures can take hours at maximum CPU load. Something that should be quite noticeable. So while they are an actual risk, they aren't an immediate risk. Just have some patience.
The Linux Weekly News usually has some pretty good information about kernel changes.
The most recent release requires a subscription, however all others are free to read.