Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for December 5, 2013
Deadline scheduling: coming soon?
LWN.net Weekly Edition for November 27, 2013
ACPI for ARM?
LWN.net Weekly Edition for November 21, 2013
Posted Feb 23, 2010 4:23 UTC (Tue) by corbet (editor, #1)
Posted Feb 23, 2010 6:44 UTC (Tue) by bojan (subscriber, #14302)
Is this directed to the above mentioned "pretentious" people? If yes, could you please point out which of my comments was disrespectful here?
Posted Feb 23, 2010 13:56 UTC (Tue) by corbet (editor, #1)
Posted Feb 23, 2010 19:09 UTC (Tue) by chad.netzer (subscriber, #4257)
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?
Posted Feb 23, 2010 23:50 UTC (Tue) by nix (subscriber, #2304)
... 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*
18.104.22.168 Release notes
Posted Feb 23, 2010 7:02 UTC (Tue) by bojan (subscriber, #14302)
First, they tell us that all bugs should be considered "normal bugs": http://kerneltrap.org/Linux/Security_Bugs_and_Full_Disclo....
Then in 22.214.171.124 (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?
Posted Feb 23, 2010 22:09 UTC (Tue) by nix (subscriber, #2304)
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
Posted Feb 23, 2010 22:36 UTC (Tue) by bojan (subscriber, #14302)
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.
> 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.
Posted Feb 27, 2010 6:30 UTC (Sat) by malor (subscriber, #2973)
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.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds