| |||||||||||||
Og returns with a new batch of stable kernelsFever-induced dreams of Og—evidently the result of consuming salmonella-infused eggs—mark the release of multiple new stable kernels. Og's alter-ego, Greg Kroah-Hartman, has released the 2.6.27.53 ("Og wondered about these people, constantly relying on the old kernels to save them for another day"), 2.6.32.21 ("Some people dressed in odd clothes, red swirls, green lizards on their heads, red hats on others, and one remaining group who, despite it being very unflattering, always wore dull brown clothing, picked up the kernel and ran away with it back to the village"), 2.6.34.6 ("It only had one kernel left in it and he threw it at the people, saying, 'this is the last one.'"), and 2.6.35.4 ("Og reached into his bag marked with a big "35" and tossed a plump, [juicy] kernel at this final group, who instantly grabbed it up, thanked him for providing it (unlike those self-absorbed 32 and 27 people) and ran off to help spread the good news of a new kernel"). In case Og-speak was not clear enough, this will be the last .34 kernel and .27 is nearing the end of its life. All users of these kernels must upgrade. (Log in to post comments)
Og returns with a new batch of stable kernels Posted Aug 27, 2010 1:22 UTC (Fri) by fuhchee (subscriber, #40059) [Link]
"All users of these kernels must upgrade."
Note that this use of the word "must" is not of the same intensity as the RFC2119 MUST, SHALL, or REQUIRED. It's more like RECOMMENDED.
Og returns with a new batch of stable kernels Posted Aug 27, 2010 1:37 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
"...we have sunk to a whole new level of professionalism." (c) You-know-who :)
Og returns with a new batch of stable kernels Posted Aug 27, 2010 22:15 UTC (Fri) by nix (subscriber, #2304) [Link]
Yeah, maintaining stable kernels is a vicious, ogly job.
Og returns with a new batch of stable kernels Posted Aug 27, 2010 2:00 UTC (Fri) by cesarb (subscriber, #6266) [Link]
I know we are not supposed to be looking for hidden messages within these announcements, but why is 27 different from the others?
- 2.6.27.53: "very strongly encouraged to upgrade"
Is it because it did not have the problematic stack guard page code, and thus did not need a somewhat urgent patch fixing it?
Og returns with a new batch of stable kernels Posted Aug 27, 2010 3:51 UTC (Fri) by gregkh (subscriber, #8) [Link]
No, because I cut and pasted from the previous announcement. Just think "must" from now on, I'm tired of people trying to parse my words.
Og returns with a new batch of stable kernels Posted Aug 27, 2010 7:38 UTC (Fri) by jengelh (subscriber, #33263) [Link]
It seems like it's only a matter of time before it (perhaps: needs to) read "Upgrade now, sucker!" - short of a pic of BA Baracus.
Og returns with a new batch of stable kernels Posted Aug 27, 2010 10:33 UTC (Fri) by cesarb (subscriber, #6266) [Link]
> I'm tired of people trying to parse my words
Sorry :(
Og returns with a new batch of stable kernels Posted Aug 27, 2010 13:27 UTC (Fri) by spender (subscriber, #23067) [Link]
You know Greg, an easy way to solve the problem that you strangely seem to run into every stable release (and make sure to let us know how much you hate this problem each time), is to remove the need for people to "parse" based on zero information.
You knew when you pushed out .19 that it was for an important vulnerability fix, but as has become the accepted practice, chose to omit any mention of security in any announcement. This leads to speculation and the "parsing" you so hate. ("Hey we just had a "stable" release 3 days ago, why this new one so soon?")
Surely it'd be easier to just say a sentence or two about what you know than write page-long childish stories to expound on the idea of how people must upgrade.
It's obvious people "must" upgrade -- the 2.6 development model causes the introduction of a plethora of bugs, exploitable and not, into supposedly "stable" kernels. The question people have is "why" they must upgrade. As in, "what trivial vulnerability was fixed this time that an attacker can own my systems with before I even have a chance to upgrade them all?" A response of "because" doesn't answer that question or solve that problem.
-Brad/Don Quixote
Og returns with a new batch of stable kernels Posted Aug 27, 2010 15:58 UTC (Fri) by iabervon (subscriber, #722) [Link]
People still using 2.6.27.x can't be expected to understand the modern "must", and so announcements have to use the "very strongly encouraged to" wording, which is less efficient but doesn't cause problems with old tools.
Og returns with a new batch of stable kernels Posted Aug 27, 2010 16:01 UTC (Fri) by fuhchee (subscriber, #40059) [Link]
Hey, whom are you calling an old tool?
Og returns with a new batch of stable kernels Posted Aug 27, 2010 3:00 UTC (Fri) by butlerm (subscriber, #13312) [Link]
"Note that this use of the word "must" is not of the same intensity as the RFC2119 MUST, SHALL, or REQUIRED. It's more like RECOMMENDED."
There isn't a RFC enforcement police either. Following RFC requirements is just a really good idea. Much less downside if not followed (in most cases) than having your server hacked into.
System designers regularly violate RFC "requirements" that they believe are not optimal for one reason or another. Linux violates RFC2581 by default for example.
Og returns with a new batch of stable kernels Posted Aug 29, 2010 9:54 UTC (Sun) by erwbgy (subscriber, #4104) [Link] Linux does however have the only RFC1149 implementation.
Og returns with a new batch of stable kernels Posted Aug 27, 2010 10:49 UTC (Fri) by farnz (guest, #17727) [Link] I suspect that the translation is more like, "I have neither time nor motivation to go through every last byte of code change and determine if it's a fix for a security hole (and if so, what the security hole is and how you'd exploit it). Further, I know that if I do make a mistake while trying to determine whether a bug is exploitable or not, I'll get flamed by a mix of people who could have done the job themselves, but are choosing not to, and people who couldn't do it, but who are happy to hurl insults from the sidelines anyway. So either step up to the plate and help me out, or upgrade."
Og returns with a new batch of stable kernels Posted Aug 27, 2010 13:02 UTC (Fri) by spender (subscriber, #23067) [Link]
Who are these people that need to step up to the plate? You seem to suggest that this is somehow my responsibility, and not the responsibility of the kernel developers themselves. You know, the people creating the software. In what other project in the world is it acceptable to shirk this responsibility?
What's the point of watering a tree that's rotten from the inside? Get rid of the "a bug is just a bug" stupidity that no one else in the world agrees with and stop playing verbal games when you know you're fixing a security vulnerability. Otherwise the only interest security people will have in the kernel is developing exploits for the vulnerabilities that hide their security impact in the commit message (though it's trivial for blackhats to spot this, especially when the fixes come from certain individuals, like in this case):
-Brad
Og returns with a new batch of stable kernels Posted Aug 27, 2010 14:38 UTC (Fri) by ummmwhat (guest, #54087) [Link] Indeed; these commit messages are just getting silly.
Og returns with a new batch of stable kernels Posted Aug 27, 2010 14:47 UTC (Fri) by farnz (guest, #17727) [Link] This is an open project; anyone who cares can step up and improve things; there are an order of magnitude more people interested in doing new shiny things than people interested in doing same old but more secure. Greg clearly (based on his actions) has enough time to backport patches with the help of the original authors, but not enough time to analyze them for security flaws. If people really do want a kernel where the announcement says "security fix for CVE xxxx-xxxx, and a fix for previously unknown vuln abc", they need to get out there and do the work themselves. Other projects are no different - security is a different mindset to feature development, and while feature developers try to get it right, they tend not to have the particular "if I wedge this crack like this, I get 4 bytes to here, and if I make those 4 bytes *this* value, I get that function to do something it wasn't expected to do at this point, then I do ... and boom! I'm in" mindset that security guys need.
Og returns with a new batch of stable kernels Posted Aug 27, 2010 15:24 UTC (Fri) by spender (subscriber, #23067) [Link]
It's an open project in the sense that if I commit a fix, I can choose the message for that fix. If that patch is then used verbatim (that isn't necessarily the case) then my message would be visible by other people.
It being an open project doesn't fix the real problem here: nobody has control over the commit messages of the kernel developers but the kernel developers themselves. It should be clear then where the responsibility lies.
Nobody's saying Greg has to analyze anything for security flaws (google LWN to see how many times we've repeated this). Take the two examples of the CAN vulnerability, which has a published exploit, and the stack overlap vulnerability, which has private exploits (and no reason for them not to become public at any minute). At commit time for both vulnerabilities, the security impact was known by the committer. Yet in both cases great pains are taken in beating around the bush regarding security impact. Really, look at the CAN fix:
There's no reason for this, and the responsibility isn't on anyone else but the committer to be honest about the code they're committing to the kernel. It doesn't hurt the blackhats or keep them from figuring out what's going on: they know who Ben Hawkes is and what kind of bugs he'd be reporting to the kernel developers.
There's no reason for intentionally pulling the wool over users' eyes all because of the misguided notion that somehow the attackers will be too dumb to figure it out.
Look at the response to the .19 announcement:
If Linus' commit message hadn't been a lie by omission, there wouldn't have been any confusion by users like cesarb as to why there were two stable releases within 3 days of each other. The fact that it was released at that time as well is quite telling (that security bugs are being treated differently, the developers just don't want you to know about them).
-Brad
Og returns with a new batch of stable kernels Posted Aug 27, 2010 15:33 UTC (Fri) by Trelane (subscriber, #56877) [Link]
I like this policy, but it's voluntary and requires each committer to agree to it. I'll try to follow it for my fixes (I likely would anyway), but I'm not a kernel hacker.
Og returns with a new batch of stable kernels Posted Aug 27, 2010 17:34 UTC (Fri) by cesarb (subscriber, #6266) [Link]
> there wouldn't have been any confusion by users like cesarb as to why there were two stable releases within 3 days of each other.
Trying to guess what is on other people's minds is fun!
There was no confusion at all there. Here is the history behind that comment:
1. I saw on LKML the report of a "data corruption on hibernation" bug, and started following its discussion. I postponed seeing if hibernation worked on my new laptop until it was fixed.
Obviously, that commit was a good reason to update as soon as possible (if you use hibernation at all), which is what I posted on that comment (http://lwn.net/Articles/400140/). That was only guesswork, of course - that was a bug which was on my mind, for other people (who might not even be considering using hibernation) the most important bug might be another one.
Note that in NO moment I ever considered or even noticed the timing of the stable release. To me, it was a normal stable release, with normal timing (I had even seen the "stable review" for it on LKML, as usual). I only wondered why such a hurry in adding Linus' commits to it so quickly after they were upstream, but thought there must be some cause.
That is, I wondered about the hurry in adding these commits to the next stable release, instead of waiting a bit more to check for regressions and adding it to the stable release after that one. I did not wonder at all about the timing of the stable release itself, as I was already expecting it on a few days since the "stable review" mailbomb went out.
Og returns with a new batch of stable kernels Posted Aug 27, 2010 17:40 UTC (Fri) by cesarb (subscriber, #6266) [Link]
(And as an addendum, in case someone is wondering: no, hibernation did not work. And now suspend to RAM has regressed as of 2.6.36-rc2+, and hangs on resume with backlight off. I have not looked into either yet to see if I can find the cause.)
Og returns with a new batch of stable kernels Posted Aug 27, 2010 18:14 UTC (Fri) by spender (subscriber, #23067) [Link]
"I only wondered why such a hurry in adding Linus' commits to it so quickly after they were upstream, but thought there must be some cause."
"Obviously, that commit was a good reason to update as soon as possible (if you use hibernation at all)"
I know you yourself weren't confused when you made your post, which specifically mentioned that you thought you had picked out the reason for the "must upgrade" warning, but your guess was wrong. You should be able to agree though that there is "confusion by users" when they wrongly interpret the reason for the release. No mention of the vulnerability that was the reason for the release, except by Eugene and I -- I call that confusion.
-Brad
Contributing to commit messages Posted Aug 28, 2010 21:08 UTC (Sat) by jrn (subscriber, #64214) [Link]
> It being an open project doesn't fix the real problem here: nobody has control over the commit messages of the kernel developers but the kernel developers themselves.
For what it's worth, others can provide addenda to commit messages using the "git notes" command. Unfortunately it is hard to collaborate on notes, though, since the 'git notes merge' functionality is not finished yet. http://thread.gmane.org/gmane.comp.version-control.git/15...
Nevertheless, sharing commit annotations is quite possible. For example, for Thomas Rast's notes for git.git:
git fetch git://repo.or.cz/git/trast.git notes/full &&
Og returns with a new batch of stable kernels Posted Aug 30, 2010 11:58 UTC (Mon) by marcH (subscriber, #57642) [Link]
> This is an open project; anyone who cares can step up and improve things; there are an order of magnitude more people interested in doing new shiny things than people interested in doing same old but more secure.
Like... systemd?
Og returns with a new batch of stable kernels Posted Aug 27, 2010 22:21 UTC (Fri) by nix (subscriber, #2304) [Link]
Uhhh... this is a vulnerability in CAN, a protocol used pretty much exclusively inside the networks you find in modern cars. I defy you to name a single car running the latest -stable kernel and routinely upgraded. Worrying about this particular vulnerability being fixed (or not being fixed) in a stable kernel is foolishness. Nobody who upgrades to recent stable kernels will be doing it on a platform for which CAN is the slightest use, except for people working for automobile manufacturers, and they are almost certainly tracking all changes to something as critical to them as CAN as a matter of course.
Og returns with a new batch of stable kernels Posted Aug 27, 2010 22:40 UTC (Fri) by spender (subscriber, #23067) [Link]
Since when has whether a protocol not being actively used stopped a local exploit from exploiting it? You know about request_module() right? And you know that at least Ubuntu shipped a vulnerable kernel, and that the exploit (which you have of course looked at) specifically targets that Ubuntu kernel?
Step 1: Do research
It goes Step 1, then Step 2. You can do it.
-Brad
Og returns with a new batch of stable kernels Posted Aug 31, 2010 11:59 UTC (Tue) by nix (subscriber, #2304) [Link]
Yeah, I could have researched this, but at the time of posting I was stuck behind a 2400bps modem link. It gets boring fast.
(And, wtf? why is Ubuntu, a *desktop-oriented* distro, shipping a network protocol aimed at cars? What were they thinking?)
Og returns with a new batch of stable kernels Posted Aug 31, 2010 13:59 UTC (Tue) by fuhchee (subscriber, #40059) [Link]
"And, wtf?"
On your favourite distribution, check out:
% ls -R /lib/modules/`uname -r`/kernel/net
There's lots there for fedora.
Og returns with a new batch of stable kernels Posted Aug 27, 2010 5:09 UTC (Fri) by ncm (subscriber, #165) [Link]
Hmm, 2.6.35.4 i915 on i5 Arrandale: Screen backlight comes on, but no fb video -- except on an external monitor. Unplug that and start X, and again backlight but no video; plug in an external monitor, and then video comes up on the main panel. Same, after suspend and resume. Same, too, after inactivity timeout.
Should I expect different behavior with 2.6.36-rc3, when it's out? Seems like -rc2 had a lot more patches than 2.6.35.4.
(Also, overheated and turned itself off while compiling a kernel... Never did that before. But happened again under 2.6.35.1. Dell. Grr.)
Og returns with a new batch of stable kernels Posted Aug 27, 2010 6:27 UTC (Fri) by tilman (guest, #46964) [Link]
> (Also, overheated and turned itself off while compiling a kernel...
> Never did that before. But happened again under 2.6.35.1. Dell. Grr.)
Interesting. I noticed the same problem in 2.6.35, also for the very first time. I assumed it was a hardware problem, but maybe it's not...
Og returns with a new batch of stable kernels Posted Aug 27, 2010 15:51 UTC (Fri) by byronclark (subscriber, #32457) [Link]
Here's the bug for that one: https://bugs.freedesktop.org/show_bug.cgi?id=29278
regression in 2.6.35 Posted Aug 27, 2010 11:46 UTC (Fri) by nicolas@jungers (✭ supporter ✭, #7579) [Link]
I'm stuck with 2.6.34 because of a regression in 2.6.35 (sata PM based on the SIL3726) https://bugzilla.kernel.org/show_bug.cgi?id=17071 Does the fact that there will be no more 2.6.34 update means that the regression will be fixed (?) or that I will have to go back to 2.6.32 or live with the perils of 2.6.34? The system being completely isolated I don't care much about security but I'd like to know what's the "official" advise.
|
|||||||||||||