User: Password:
|
|
Subscribe / Log in / New account

2.6.32.9 Release notes

2.6.32.9 Release notes

Posted Feb 22, 2010 21:24 UTC (Mon) by nix (subscriber, #2304)
In reply to: 2.6.32.9 Release notes by jake
Parent article: 2.6.32.9 Release notes

This thread is surely proof of your expectation. The usual suspects are
flaming and alleging bad faith and incompetence in a thread responding to
a post doing *exactly what they've been bellyaching about for years*.

It is quite plain by this point that they are impossible to satisfy.


(Log in to post comments)

2.6.32.9 Release notes

Posted Feb 22, 2010 21:36 UTC (Mon) by PaXTeam (guest, #24616) [Link]

did hayfever season come early? how about you actually read the posts you're supposedly forming your utterly uninformed opinion about ;).

2.6.32.9 Release notes

Posted Feb 22, 2010 23:06 UTC (Mon) by nix (subscriber, #2304) [Link]

Amazing. Whenever I thought I'd seen you be the acme of unpleasantness,
you beat your record.

I *really* want a killfile for LWN. There'd only be two names on it for
me... hm, actually, three, petegn deserves to be on it too.

2.6.32.9 Release notes

Posted Feb 22, 2010 23:56 UTC (Mon) by spender (subscriber, #23067) [Link]

You could always pretend as if such a killfile existed. I would welcome this change!

Sincerely,
-Brad

2.6.32.9 Release notes

Posted Feb 23, 2010 4:03 UTC (Tue) by chad.netzer (subscriber, #4257) [Link]

Perhaps a Greasemonkey script can be whipped up for those of us who feel
that the ridiculous pretentiousness of spender, PaxTroll, bojan, et al. are
ruining LWN discussions?

Comment filtering

Posted Feb 23, 2010 4:23 UTC (Tue) by corbet (editor, #1) [Link]

A comment filtering mechanism is in the works, has been for a little while. I hope that people won't use it much, though; it would be better if we could express our disagreements in a more respectful manner...

Comment filtering

Posted Feb 23, 2010 6:44 UTC (Tue) by bojan (subscriber, #14302) [Link]

> it would be better if we could express our disagreements in a more respectful manner...

Is this directed to the above mentioned "pretentious" people? If yes, could you please point out which of my comments was disrespectful here?

Comment filtering

Posted Feb 23, 2010 13:56 UTC (Tue) by corbet (editor, #1) [Link]

It was not directed at anybody in particular, believe it or not. I just wish, in general, that the tone of the conversation would be a bit more respectful and that people would focus more on the issues and not other people...

Comment filtering

Posted Feb 23, 2010 19:09 UTC (Tue) by chad.netzer (subscriber, #4257) [Link]

And though I listed you as "pretentious", I would not put you in the same
class as PaxTroll or spender, who go out of their way to be condescending
primadonnas. And corbet would likely label me as disrespectful in these
comments (it's true; I do *not* respect the above two I mentioned).

The LWN comment section is not well suited to these kinds of opinionated
"discussions", since there are no tools to control the threading, collapsing
and rating of comments, etc. Hence, the same points keep getting
fruitlessly reargued. Not sure its fixable, but a simple filter *might* help
with signal to noise for those that want to have a novel discussion.

Meanwhile, I'd rather talk about things like which of these fixes actually
solve an issue for people. We have been testing #36 for a short while,
since the umount bug it fixes was actually hitting us in practice. It'd be
nice to talk about something like who here is actually using and testing the
2.6.32.y series, and what issues have they had?

Comment filtering

Posted Feb 23, 2010 23:50 UTC (Tue) by nix (subscriber, #2304) [Link]

2.6.32.x has actually been by far my least problematic kernel series in
ages. 2.6.31 had e1000e flow control lossage for me, and a couple of
oopses, rapidly fixed; 2.6.30 had e1000e 82574L jumbo frame lossage and a
single unreproducible incident of massive ext4 filesystem corruption (well
I say 'massive' but fsck fixed it completely: it just took it half an hour
of flooding messages across the screen). 2.6.32 has had nothing wrong at
all, other than an obscure and hard-to-track-down intel-hda ALSA bug,
exhibited only by PulseAudio complaints.

... or, rather, the only wrong thing is an explosion of almost totally
idle ext4 direct I/O kernel threads: one per CPU per sb. That's 96 or
something on my machine. I only want direct I/O for *one filesystem*
dammit!

2.6.32.9 Release notes

Posted Feb 23, 2010 7:02 UTC (Tue) by bojan (subscriber, #14302) [Link]

Maybe you like accepting a view given to you by Linus and other kernel developers as is. I find it confusing and illogical.

First, they tell us that all bugs should be considered "normal bugs": http://kerneltrap.org/Linux/Security_Bugs_and_Full_Disclo....

Then in 2.6.32.8 (http://lwn.net/Articles/373579/), just a while ago, we are told that, yes, there are security bugs. But, we cannot know which ones they are, although kernel developers already know, because they took special steps to make sure they were properly backported and tested.

In the meantime, we are STRONGLY encouraged to upgrade. Why strongly? Why not just normally? After all, security bugs are just normal bugs, right?

Now, please, tell me what is pretentious about asking to square up the above? I do not see how both can be true. Either security bugs are special (given that kernel developers are obviously giving them special treatment) or they are not. Also, if they already know about them, why can't we be told?

2.6.32.9 Release notes

Posted Feb 23, 2010 22:09 UTC (Tue) by nix (subscriber, #2304) [Link]

I think you got that backward. It's not that security bugs are normal
bugs, therefore security bugs are as unimportant as normal bugs: it's that
in an unprotected environment like the kernel, almost any bug could
potentially be a security bug (although it might be hard to exploit if,
say, it requires module unloading to trigger). i.e., normal bugs are
potentially as important as security bugs -- but it is quite impractical
to consider them *actually* as important as security bugs, because so very
many bugs are fixed all the time. They're merely *potential* security
bugs. And this is true of most bugs when they're fixed.

I don't agree with Linus that bugs that are *known* to be security bugs at
the time they're fixed shouldn't be called out as such and backported. I
do agree that it's impractical to expect the security implications of all
bugs to be spotted by the person who fixes them at the time the fix is
made: even if it is obvious to a steeped-in-security guy like spender, it
may not be obvious to everyone.

I'd assume that everyone involved in kernel programming knows how bad
buffer overruns and wild pointer dereferences are. After the recent
palaver I'd hope they'd know that NULL pointer dereferences are bad too.
But there are lots of other classes, and some are rare enough that I
wouldn't know them if I saw them, and might not even know them if they
were pointed out to me. (This is where spender's published exploits are
especially useful to whitehats, IMNHSO: for didactic purposes. He puts
comprehensible comments in the damn things! You can use any random
blackhat's exploit to see if your machine is vulnerable, but if you want
to know how that class of exploit works, and thus why the vulnerability is
a vulnerability, you need more than a pile of incomprehensible uncommented
shellcode.)

2.6.32.9 Release notes

Posted Feb 23, 2010 22:36 UTC (Tue) by bojan (subscriber, #14302) [Link]

> I think you got that backward. It's not that security bugs are normal bugs, therefore security bugs are as unimportant as normal bugs:

Not my words, actually. Directly from Linus:

"I personally consider security bugs to be just 'normal bugs'. I don't cover them up, but I also don't have any reason what-so-ever to think it's a good idea to track them and announce them as something special."

> it's that in an unprotected environment like the kernel, almost any bug could potentially be a security bug (although it might be hard to exploit if, say, it requires module unloading to trigger). i.e., normal bugs are potentially as important as security bugs -- but it is quite impractical to consider them *actually* as important as security bugs, because so very many bugs are fixed all the time. They're merely *potential* security bugs.

Completely agree.

> I don't agree with Linus that bugs that are *known* to be security bugs at the time they're fixed shouldn't be called out as such and backported.

And that is the crux of the issue here. What is being asked is actually quite simple. If the kernel developers know it's a security issue (by determining that themselves or by being told by someone experience in security), they should tell the rest of us. No extra effort required.

All other bugs, of course, can still turn out to be security issues. Such is kernel life, I guess. I'd say everyone is aware of that by now.

2.6.32.9 Release notes

Posted Feb 27, 2010 6:30 UTC (Sat) by malor (guest, #2973) [Link]

Yeah.... I, for one, totally don't expect them to spend a bunch of extra work figuring out if something is a security problem. But I DO expect them to pass along if it's a confirmed security issue if they already know about it. Deliberately obfuscating that information only hurts me. It can't possibly help. The ONLY thing it "helps" is that people get less pissed about security holes.

Having the same number of actual bugs, but being less aware of security holes, is actively dangerous. I consider it egregious behavior to deliberately mislead people about the nature of security fixes.

2.6.32.9 Release notes

Posted Feb 22, 2010 21:46 UTC (Mon) by bojan (subscriber, #14302) [Link]

> It is quite plain by this point that they are impossible to satisfy.

What is impossible to satisfy is illogical explanations about why things that were known to be security problems never got disclosed as such. The latest obfuscation by Linus is a clear case in point. The announcement of the .8 release is another.

If something as implemented is nonsense, expect questions. Waving a magic wand in the hope that these questions will vanish won't work. Neither will same illogical explanations.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds