|
|
Subscribe / Log in / New account

2.6.32.9 Release notes

This article brought to you by LWN subscribers

Subscribers to LWN.net made this article — and everything that surrounds it — possible. If you appreciate our content, please buy a subscription and make the next set of articles possible.

By Jonathan Corbet
February 21, 2010
Stable kernel update announcements posted on LWN have a certain tendency to be followed by complaints about the amount of information which is made available. It seems that there is a desire for a description of the changes which is more accessible than the patches themselves, and for attention to be drawn to the security-relevant fixes. As an exercise in determining what kind of effort is being asked of the kernel maintainers, your editor decided to make a pass through the proposed 2.6.32.9 update and attempt to describe the impact of each of the changes - all 93 of them. The results can be found below.

Disclaimers: there is no way to review 93 patches in a finite time and fully understand each of them. So there are probably certainly errors in what follows. The simple truth of the matter is that it is very hard to say which fixes have security implications; a determined attacker can find a way to exploit some very obscure bugs.

Your editor would also like to discourage anybody from thinking that this will become a regular LWN feature. The amount of work required is considerable; it's not something we're able to commit to doing for every release.

That said, here's a look at what's in this update.

Security-related fixes

Other bug fixes

Enhancements

Conclusions

Out of 93 patches, 18 struck your editor as having clear security implications. Quite a few other patches fix crashes which could possibly be security problems; if they are not listed as such, it's because there was no immediately evident way that a user could trigger the problem. Doubtless people with more imagination will figure out ways to take advantage of some of these bugs.

What it comes down to is that the identification of security problems is often hard. In the kernel environment, almost any bug could potentially create some kind of vulnerability. So it is not surprising to see developers "silently fix" security bugs; they simply fix bugs without realizing the implications. It is also not surprising that some developers are reluctant to call attention to security-related fixes. The list above almost certainly includes "security fixes" for bugs that nobody can exploit while classifying true vulnerabilities as mere bug fixes. Any list of security-relevant patches is sure to be an incomplete and partially deceptive thing.

That said, it may well be that fixes which are truly known to have security implications should be marked as such. Attackers will make the effort to figure that out anyway; it's not clear that making life harder for everybody else has any benefits. Still, those who would complain about how the stable tree is managed would do well to remember that, a few years ago, we had no such tree. It came into being because people stepped up to do the work of maintaining it. There can be no doubt that a better job could be done here (as is the case almost everywhere else too); its just a matter of somebody finding the time and the energy to do it.

Index entries for this article
KernelReleases/2.6.32
SecurityLinux kernel

(Log in to post comments)

2.6.32.9 Release notes

Posted Feb 21, 2010 19:11 UTC (Sun) by nelhage (subscriber, #59579) [Link]

I'm curious why you marked '#1 Fix potential crash with sys_move_pages.' as
non-security. I am not aware of any path to privilege escalation from this
bug, but it's definitely a denial of service, and an impressively effective
information leak attack (as demonstrated by spender's published exploit
code). It's been assigned CVE-2010-0415 in light of this.

#1

Posted Feb 21, 2010 19:14 UTC (Sun) by corbet (editor, #1) [Link]

Because I blew it, apparently. I couldn't see any sort of reliable way to trigger it, so it just looked like a crash. Obviously, I was unaware of the exploit or the CVE number. Clearly, it's a security problem.

2.6.32.9 Release notes

Posted Feb 21, 2010 19:23 UTC (Sun) by nelhage (subscriber, #59579) [Link]

Also, I believe '#43: KVM: PIT: control word is write-only.' is CVE-2010-
0309, and is a potential guest -> host denial of service.

Thanks for doing this experiment! It just goes to show how difficult it is
even for a kernel hacker who follows the kernel closely to figure out which
bugs have potential security impact.

Of course, I'm sure some will take that as evidence that we shouldn't even
try, while spender will tell us that this is why Linus, Greg K-H et al. need
be the ones doing it. I won't take a side here, but I think this was
definitely an interesting experiment, and hopefully will lead to interesting
discussion.

2.6.32.9 Release notes

Posted Feb 22, 2010 9:30 UTC (Mon) by dgm (subscriber, #49227) [Link]

> It just goes to show how difficult it is even for a kernel hacker who follows the kernel closely to figure out which bugs have potential security impact.

This is correct. I would add that given enough time, a determined hacker, and a convenient definition of security, any bug has the potential of having security consequences. Thus, I have to agree with Linus that time spent in assessing if a certain bug is or is not security related is time wasted. Just fix it and move on, or better yet prevent it from happening.

2.6.32.9 Release notes

Posted Feb 22, 2010 14:59 UTC (Mon) by cwarner (guest, #47176) [Link]

If you are knowingly aware it is a security issue your fix may solve the bug but
not the security issue and/or cause another security exploit. Just fixing bugs
isn't understanding how a piece of code works in its entirety. Wholeness and
correctness for a module is important.

2.6.32.9 Release notes

Posted Feb 21, 2010 21:11 UTC (Sun) by neilbrown (subscriber, #359) [Link]

Maybe here is a case for the "Impact" tag that was discussed some time ago. Then you could generate this report automatically be combining the Subject and Impact....

Impact

Posted Feb 21, 2010 21:22 UTC (Sun) by corbet (editor, #1) [Link]

That, of course, would require that developers truly understand the impact of their fixes. Maybe someday we'll all be sufficiently aware to write lines like: 

    Impact: Stop turning machines into botnet fodder

Most of us, though, just think "it fixed another bug."

Impact

Posted Feb 21, 2010 22:18 UTC (Sun) by nix (subscriber, #2304) [Link]

Git notes might help here, by allowing Impact: lines to be adjusted
after-the-fact.

Impact

Posted Feb 22, 2010 5:10 UTC (Mon) by neilbrown (subscriber, #359) [Link]

In the present context, we only really need "impact" for something that is going in to -stable. When it goes into -stable it is a new commit and so the commit message can be adjusted then.
When a patch is being submitted the -stable, the submitter presumably can justify the request for the patch to go into stable. If that justification were written is clear succinct text (the hard part!) and placed in an 'Impact:' line, then these release notes would be already written.

2.6.32.9 Release notes

Posted Feb 21, 2010 21:14 UTC (Sun) by ajb (guest, #9694) [Link]

I wonder if it would work better just to mark the non-security patches?

2.6.32.9 Release notes

Posted Feb 22, 2010 1:17 UTC (Mon) by vonbrand (guest, #4458) [Link]

How on earth would our gracious editor (or anybody else for that matter) make sure the fix has *no* security implications?

Besides, this being the patches vetted for inclusion in -stable, it stands to reason that most (all?) are potentially very serious (that is not the same as "all-around security relevant")

2.6.32.9 Release notes

Posted Feb 22, 2010 7:16 UTC (Mon) by ajb (guest, #9694) [Link]

By being conservative. It would always be safe to leave off the mark, if it marks non-security critical patches. Whereas currently many patches which are probably are security critical don't get marked. A non-security-critical mark could probably only be applied to feature additions.

2.6.32.9 Release notes

Posted Feb 22, 2010 17:11 UTC (Mon) by vonbrand (guest, #4458) [Link]

How is "leave off the not-sensitive mark" different from what goes on today? Just to be on the safe side, as a developer/integrator I'd leave it off always... and as a consumer I'd presume all patches in -stable are potentially security sensitive, just like today.

2.6.32.9 Release notes

Posted Feb 21, 2010 21:37 UTC (Sun) by arjan (subscriber, #36785) [Link]

this seems to be a clear proof that almost any kernel bug is a security issue....

Now that we have this long list of clearly identified security issues.... are we going to see really big security updates for the distros that don't keep up with the latest kernels? (esp. the enterprise kernels)
or are users of those kernels just going to keep the security issues....

2.6.32.9 Release notes

Posted Feb 22, 2010 18:22 UTC (Mon) by sht (guest, #46093) [Link]

Yes. What I've always found missing from the stable work is a reference to the commit that introduced the bug/error condition, i.e. a tag like

Bug-since: <commit>

This should be possible to determine for the majority of patches I'd guess and it would be machine checkable for backporters.

2.6.32.9 Release notes

Posted Feb 23, 2010 1:33 UTC (Tue) by bfields (subscriber, #19510) [Link]

I occasionally wonder whether the "Bug-since:" pointer shouldn't just be the parent pointer....

That is to say, when applying a simple bugfix, first check out the commit that introduced the bug and commit there--at least in cases where the merge into recent upstream would be easy.

2.6.32.9 Release notes

Posted Feb 21, 2010 22:01 UTC (Sun) by PO8 (guest, #41661) [Link]

As someone who has whined mildly in the past about the amount of information posted in these "the next Linux version is out" posts, let me be among the first to thank you for the tremendous amount of work you put into this! Wow!

That said, I guess I should make clear that this is *way* more than I was asking for. I would be perfectly happy to have the line "the usual security and bug fixes" which would cover 90% of this list. What I'm hoping would be possible is to additionally try to capture some information about a couple of specific changes that a lot of folks on LWN might care about (for example, I found the ALSA divide-by-zero fix really interesting as an example of "kludge it for now") and summarize what systems were most impacted by the changes (in this release, it looks like NFS and i915 were well-represented).

Maybe this is still too much work to do on every release. But honestly, an article that just tells me to go do a git pull without other information is little better than noise; if that's the best that can be done I personally would be happy to just skip these announcements altogether.

Again, though, my thanks! That was a really interesting exercise, and I really appreciate it.

2.6.32.9 Release notes

Posted Feb 21, 2010 22:19 UTC (Sun) by nix (subscriber, #2304) [Link]

And doing it on a Sunday! Valour beyond the call of duty...

2.6.32.9 Release notes

Posted Feb 22, 2010 1:13 UTC (Mon) by vonbrand (guest, #4458) [Link]

But honestly, an article that just tells me to go do a git pull without other information is little better than noise; if that's the best that can be done I personally would be happy to just skip these announcements altogether.

If nothing else, they might wake up somebody asleep at the wheel...

2.6.32.9 Release notes

Posted Feb 21, 2010 22:27 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

BTW, this content might be better placed in free section, not paywalled. It's security-related, after all.

2.6.32.9 Release notes

Posted Feb 22, 2010 15:08 UTC (Mon) by foom (subscriber, #14868) [Link]

But it was also lot of work, and those who haven't paid don't need to know more than the Kernel
release announcement says ("you should upgrade") anyways.

2.6.32.9 Release notes

Posted Feb 21, 2010 23:03 UTC (Sun) by spender (guest, #23067) [Link]

Very interesting experiment, thanks for doing this!

One thing I noticed that would take little effort and help improve clarity for the bugs marked as security-relevant would be to provide some context to included oops/BUG in the commit messages. If it's for a resident device like a soundcard, did the oops occur prior to init, or was it triggered at runtime by a user?

Seeing oops messages consistent with a particular exploitable bugclass always sets off alarms, but in many instances the bugs just aren't reachable by an attacker. A few extra words of context could help.

Some of the ones you missed (the move_pages() one for example that I wrote an exploit for) would have been caught if the information known by the committer (Linus in this case) had made it into the commit message. That particular bug was reported by SuSE security and its impact was known. It was even reported to SuSE as having security impact. It's a good example of how deliberate obfuscation hurts the wrong people. In this case, you didn't spot it as being security relevant, while I wrote an exploit for it.

-Brad

2.6.32.9 Release notes

Posted Feb 22, 2010 1:05 UTC (Mon) by eteo (guest, #36711) [Link]

Yes, these are useful information. Also, including links to mailing list posts and bugzilla bug reports (if any) would help improve clarify too.

2.6.32.9 Release notes

Posted Feb 22, 2010 17:32 UTC (Mon) by vonbrand (guest, #4458) [Link]

I'm sorry, but I've to side with the developers here.

Just imagine you (as developer) get a bunch of (mostly incomplete, often conflicting) problem reports, and you are at the end able to track down what seems to be the cause. You fix it, and go your merry way chasing the next bug. Or you then sit down trying to organize the whole mess to create an intelligible commit message/impact assesment. Better skip the second part, as it slows down the fixing of bugs. Besides, your assesment could very well be dead wrong (see the oversights in the article for examples), or it might even be that while researching one problem you find (and fix) a completely unrelated issue. Is the poor developer then forced to search all over the reports to check if it fixes something else? This being open source, if somebody wants accurate bug impact assesments, they are more than welcome to contribute the required expertise and manpower to compile and publish them. That this hasn't shown up (only whining that it is not out for grabs) indicates that the need really isn't there...

Bugs are bugs, they need to be fixed. Sure, we know by now that anything that could lead to following a bogus pointer (including NULL), or writing past allocated space, or sloppy locking, among others can lead to security problems, and such patches get priority going to stable. Other stuff can be handled with a more cavalier attitude, as long as it isn't shown that it causes (security) trouble.

I just fail to see what could be gained by labeling some bugs as security-sensitive while others aren't. The labeling won't ever be correct, so your best bet is to apply all patches. If that isn't enough for your level of paranoia, you won't trust the labels anyway, and (re)do the checking. This is quite beside the fact that what would be a mild or nonexistent problem for one configuration might be lethal in another one.

2.6.32.9 Release notes

Posted Feb 22, 2010 18:19 UTC (Mon) by spender (guest, #23067) [Link]

You should give your opinions some context, so that others can know if they should listen to anything you have to say.

1) What distro do you use?
2) How many servers do you maintain?
3) How many (estimated) users are there on those servers total?
4) What kind of services are provided by the systems?
5) How often do you upgrade your kernels?
6) How many desktops do you maintain?
7) What kernel are you currently running?

It's obvious you don't do anything in security, and your arguments are nothing but arguing with scenarios you imagined up to suit your own apologist view.

I'd appreciate your answers to the questions above so I can get some perspective on users who share your view (as there seem to be a couple like you on this site).

-Brad

2.6.32.9 Release notes

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

Why should he? We don't know anything of the kind about you lot
(especially not PaXTeam). Nor should we need to.

For a security person you seem to be asking for an appalling amount of
personal info here. Doesn't privacy matter?

2.6.32.9 Release notes

Posted Feb 22, 2010 20:45 UTC (Mon) by chad.netzer (subscriber, #4257) [Link]

Wow, Brad. How bogus of you. vonbrand's commentary stands on it's own,
and hardly needs to be vetted. If you disagree with any particular points, you
are free to respond to them, or ignore them. People disagree with you on
this, deal with it (or be more convincing). Meanwhile, you simply reinforce the
label that Linus put out there: "primadonna"

BTW, thanks to LWN for another great article.

2.6.32.9 Release notes

Posted Feb 26, 2010 0:29 UTC (Fri) by malor (guest, #2973) [Link]

Labeling people is a very convenient way of ignoring true, but uncomfortable things.

2.6.32.9 Release notes

Posted Feb 26, 2010 2:23 UTC (Fri) by chad.netzer (subscriber, #4257) [Link]

You are absolutely correct; an "ignore" label *would* be awfully convenient.

2.6.32.9 Release notes

Posted Feb 26, 2010 2:48 UTC (Fri) by malor (guest, #2973) [Link]

And wouldn't change the fact that he's right.

2.6.32.9 Release notes

Posted Feb 26, 2010 4:06 UTC (Fri) by chad.netzer (subscriber, #4257) [Link]

I accept your apology.

2.6.32.9 Release notes

Posted Feb 23, 2010 11:59 UTC (Tue) by NAR (subscriber, #1313) [Link]

You fix it, and go your merry way chasing the next bug. Or you then sit down trying to organize the whole mess to create an intelligible commit message/impact assesment. Better skip the second part, as it slows down the fixing of bugs.

No, the job of the software developer is not only to fix bugs, but create useful commit messages, because somebody else might look at the same code a couple of years later and would like to know why that change was introduced.

2.6.32.9 Release notes

Posted Feb 23, 2010 13:23 UTC (Tue) by hppnq (guest, #14462) [Link]

No, the job of the software developer is not only to fix bugs, but create useful commit messages, because somebody else might look at the same code a couple of years later and would like to know why that change was introduced.

There is a fundamental difference between a commit message that accurately describes what was fixed (which is not dependent on any other context than the code that was touched), and an assessment of the impact of that fix in what could be a huge range of contexts, most of which have little or nothing to do with the actual implementation.

Not knowing how and when to distinguish between these two is what makes these flamefests discussions such a waste of spacetime.

2.6.32.9 Release notes

Posted Feb 22, 2010 0:39 UTC (Mon) by eteo (guest, #36711) [Link]

Jonathan, thanks for writing this article. I'm glad I'm not the only one doing these now ;) You might want to subscribe to http://seclists.org/oss- sec/ where we keep track of both kernel (and non-kernel) security issues in upstream open source projects. Of course, that includes the regular stable kernel updates too. -Eugene

2.6.32.9 Release notes

Posted Feb 22, 2010 0:53 UTC (Mon) by eteo (guest, #36711) [Link]

CVE-2010-0415 #1: Fix potential crash with sys_move_pages
CVE-2010-0622 #2: futex_lock_pi() key refcnt fix
CVE-2010-0623 #3: futex: Handle user space corruption gracefully
CVE-2010-0309 #43: KVM: PIT: control word is write-only
infoleak #79: USB: usbfs: only copy the actual data received
memleak #80: USB: usbfs: properly clean up the as structure on error paths

I might have missed a couple more, please check the oss-sec mailing list.

2.6.32.9 Release notes

Posted Feb 22, 2010 11:12 UTC (Mon) by error27 (subscriber, #8346) [Link]

Hi Eugene. Is there a web page or something that has a list of CVEs for each stable release? Seems like kernelnewbies could put this on a wiki or something.

2.6.32.9 Release notes

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

i already posted these to the 32.8 stable thread: http://cve.mitre.org/cve/cve.html and http://web.nvd.nist.gov/view/vuln/search . these are US government sponsored efforts to collect and catalog vulnerability information, for over a decade now. there're also other collections like bugtraq/vupen/secunia/etc but CVE is considered the etalon these days i think.

2.6.32.9 Release notes

Posted Feb 22, 2010 12:39 UTC (Mon) by eteo (guest, #36711) [Link]

There isn't one yet. It requires some effort but it shouldn't be difficult to do this. Just monitor the oss-security mailing list, and the two other links that PaXTeam posted in his reply.

Thanks

Posted Feb 22, 2010 2:52 UTC (Mon) by bamakojeff (guest, #33175) [Link]

I found this summary fascinating and really enjoyed looking through it. Thanks so much for taking the time to do it.

Yet another reason why my wife knows what's number one on my Christmas wish list - renew my LWN subscription!

2.6.32.9 Release notes

Posted Feb 22, 2010 4:24 UTC (Mon) by clugstj (subscriber, #4020) [Link]

Thank you for this Jon.

Now would all you whiners that keep saying that the kernel developers should spend all of their time determining if this or that bug could be a security problem for you in particular please GET A CLUE!

2.6.32.9 Release notes

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

Nobody ever suggested that kernel developers should do any such thing. What was suggested was that when kernel developers _already_ know that something has security implications they should tell the rest of us. And no, this does _not_ mean that other fixes are not security related, just that kernel developers don't know whether they are or not.

2.6.32.9 Release notes

Posted Feb 22, 2010 5:57 UTC (Mon) by spender (guest, #23067) [Link]

Let them have their straw men. People like clugstj who keep bringing up and attacking things that no one on the "complaining" side has said are people that haven't listened to a single word for the past 2 years. I'm curious what form of Linux these anti-complainers are using -- since they act as if this issue doesn't affect Linux users at all.

I'd also like to say something about the last paragraph of the article. "Those who would complain about how the stable tree is managed" "do well to remember" a few years ago when Chris Wright was involved in the stable releases as well. The official policy was different back then, and it's gone downhill since he stopped being involved. As for insinuating that the complainers (which would include me) haven't stepped up to offer time/energy, I'd like to point out that in July 2008 around the time when this issue was first heavily debated, the PaX Team and myself offered our free time to do similar cursory write-ups on the stable releases. Jake had presented the idea to us and said it would be hosted on LWN. Nothing had ended on a sour note, but the last email we received about it was the day after the first email we received about it. We didn't hear anything else back until we asked about it ourselves again in January of 2009. Apparently in the meantime Jake thought "it might not be very productive" and failed to inform us that he scrapped the idea.

Like Eugene mentioned, some of us are putting forth the effort to bring some honesty to the security of the kernel. If you look at Linus' ridiculous changelog message for move_pages(), at the lengths he went through to take the accurate, useful information he was given and turn it into something pointlessly obfuscated (when the two line fix screams of fixing completely nonexistent bounds checks), you'll understand why the work of the "complainers" is important. It's surprising, actually, given Linus' hatred for embargoes -- he wants users to have the security bugs fixed and not have to wait an arbitrary amount of time for it. How does he expect these fixes to get back to actual users if he actively works to hide them?

Seriously, look at it:
>From: Linus Torvalds <torvalds@linux-foundation.org>
>
>commit 6f5a55f1a6c5abee15a0e878e5c74d9f1569b8b0 upstream.
>
>We incorrectly depended on the 'node_state/node_isset()' functions
>testing the node range, rather than checking it explicitly. That's not
>reliable, even if it might often happen to work. So do the proper
>explicit test.
>
>Reported-by: Marcus Meissner <meissner@suse.de>
>Acked-and-tested-by: Brice Goglin <Brice.Goglin@inria.fr>
>Acked-by: Hugh Dickins <hugh.dickins@tiscali.co.uk>
>Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
>
>---
> mm/migrate.c | 3 +++
> 1 file changed, 3 insertions(+)
>
>--- a/mm/migrate.c
>+++ b/mm/migrate.c
>@@ -953,6 +953,9 @@ static int do_pages_move(struct mm_struc
> goto out_pm;
>
> err = -ENODEV;
>+ if (node < 0 || node >= MAX_NUMNODES)
>+ goto out_pm;
>+
> if (!node_state(node, N_HIGH_MEMORY))
> goto out_pm;

I can imagine fixes for buffer overflows being worded like:
"We incorrectly depended on strcpy for testing the array size, rather than checking it explicitly. That's not reliable, even if it might often happen to work. So do the proper explicit test."

-Brad

2.6.32.9 Release notes

Posted Feb 22, 2010 10:57 UTC (Mon) by tialaramex (subscriber, #21167) [Link]

"the PaX Team and myself offered our free time to do similar cursory write-ups on the stable releases"

It's not clear from this whether you merely offered (it's easy to offer) or whether you actually did it. If you did, links please? It might be interesting to see whether your attempts were any better than our esteemed editor.

2.6.32.9 Release notes

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

> If you did, links please?

it was a private discussion via email and i think i'm not at liberty to quote it without consent but if the other participants agree to make them public, so do i.

2.6.32.9 Release notes

Posted Feb 22, 2010 12:44 UTC (Mon) by tialaramex (subscriber, #21167) [Link]

Maybe I didn't make myself clear, I am asking if these "cursory write-ups" actually exist. It seems not. Obviously any number of people could volunteer to write such things, but that's worthless unless they actually do it.

The write ups themselves would not constitute part of a "private discussion"

2.6.32.9 Release notes

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

> Maybe I didn't make myself clear,

no, you were just being dense as usual. try to read the sentences next to what you quoted and understand that the whole effort sort of died down and not because we wanted it.

> I am asking if these "cursory write-ups" actually exist.

i can't speak for spender here but i keep my own logs on various commits here for stuff that i find relevant for myself (not necessarily security related either). but that's a private list and not what we were going to publish.

> It seems not.

it seems you're just trolling as usual. but if you want to get a taste of what was going to be published, read spender's twitter stream where he pointed out several silently fixed security bugs over the past months, many if not all of them without a CVE at the time. reminds me, did the sparc64 NX bug get a CVE already?

> The write ups themselves would not constitute part of a "private discussion"

what's private and what's not is not for you to decide.

2.6.32.9 Release notes

Posted Feb 22, 2010 17:39 UTC (Mon) by vonbrand (guest, #4458) [Link]

I'm sorry, but you claim to be doing the work of travelling the patches and checking them for security relevance, and do not publish the results, while complaining others don't publish the very same data (which they arguably don't have at hand)?

I just can't imagine our esteemed editor refusing a volunteer column like the article we are talking about here.

2.6.32.9 Release notes

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

> I'm sorry, but you claim to be doing the work of travelling the patches

some commits, yes.

> and checking them for security relevance,

i mostly check them for interference with my work and that necessarily means that sometimes my eyes catch security relevant commits as well.

> and do not publish the results

i don't understand what is there to publish. aren't all bugs just bugs? what else do *you* want to know about them? you can't defend the coverup of security bugs and complain about their lack of disclosure at the same time. make up your mind ;). also you're welcome to follow spender's twitter stream, we often inform each other about suspicious commits and investigate together.

> while complaining others don't publish the very same data (which they arguably don't have at hand)?

i never complained about not disclosing security impact information they do not themselves have already. quote me back if you believe otherwise. what i did and still do complain about is when they *know* that a commit fixes a security bug but cover it up.

> I just can't imagine our esteemed editor refusing a volunteer column like the article we are talking about here.

it wasn't him (Jon) and it wasn't going to be part of LWN but rather a reply to -stable postings on lkml (spender went back and double checked the emails).

2.6.32.9 Release notes

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

Now, now, spender at least publishes the results by emailing md5sums of
descriptions of bugs to people. Surely that is sufficient for anyone.

</snark>

2.6.32.9 Release notes

Posted Feb 22, 2010 17:45 UTC (Mon) by vonbrand (guest, #4458) [Link]

I fail to see any problem with the changelog entry. A range test was mistakenly omited, add it. Sure, this particular missing range check can have disastrous consecuences, just as there are probably a dozen others added the same way that are "can't happen"s or have little or no impact. The log entry describes what was wrong with the code, as it should.

2.6.32.9 Release notes

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

I think Linus went a bit far here. He was actually *told* that it would
have disastrous consequences, and shown how: he should probably have
mentioned as much in the log message. This did seem to be played down
entirely too much for my liking.

2.6.32.9 Release notes

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

On the funny side of things, the 2.6.32.8 release reads like a plot of a Monty Python skit: a security problem was fixed after intensive scrutiny, but we don't know which one it was. Hilarious! :-)

2.6.32.9 Release notes

Posted Feb 22, 2010 19:07 UTC (Mon) by clugstj (subscriber, #4020) [Link]

It's not a straw man. I'm too lazy to look it up, but nearly every time that there is a security problem in a kernel update, someone belly aches that the kernel developers should figure out for if this bug is a security problem for them.

It's very hard work to do this even in the general case. I'd much rather the kernel developers spend their time FIXING bugs than trying to imagine the possible uses a black hat could have for it.

I didn't point anyone out explicitly, but it does appear that I hit a nerve.

2.6.32.9 Release notes

Posted Feb 22, 2010 19:22 UTC (Mon) by spender (guest, #23067) [Link]

Not only are you too lazy to look it up, but if you try you won't find anything. I did a simple search for you, so you can see what we've said *repeatedly* and exactly why you're attacking a straw man.

http://lwn.net/Articles/286263/
"Willy, please do read the previous discussion before commenting. the problem isn't that people are unable to determine whether a given bug has a security impact or not. that is a separate issue and is not the point raised now. the problem we exposed is that of covering up security impact information when it *is* already known to the kernel developers."

"2. as you were told about a dozen times already, the problem isn't with not recognizing a bug for its security impact (or rather, that's a separate problem), but the intentional omission of such information when it is already known."

http://lwn.net/Articles/290570/
"yes, it would be the next step after the already known security issues are acknowleged at least."

http://lwn.net/Articles/373731/
"And again, before anyone brings it up again, it's not about the developers themselves trying to figure out if every bug is a security bug -- it's about not hiding or obfuscating what they are clearly aware of."

"If you don't omit the security information you're aware of, nothing changes on the blackhat side because they can already spot developer weasel words when the developers are committing a vulnerability fix."

I look forward to your apology.

-Brad

2.6.32.9 Release notes

Posted Feb 22, 2010 20:16 UTC (Mon) by clugstj (subscriber, #4020) [Link]

Pardon me if I don't believe your "search" - it could be a bit biased. Why would I apologize to you? Did I mention you or the others going bonkers in this thread by name at any point in this discussion?

If you told a kernel developer that such and such a bug has this security impact, why should he automatically believe you? Unless he very much trusts your opinion or has the time to check your findings, he would be foolish to do so.

I made the original comment for two reasons:

1) I have seen the kind of comment of which I speak. I never said it was from you, nor did I have you in mind.
2) I don't mind stirring the pot.

2.6.32.9 Release notes

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

> If you told a kernel developer that such and such a bug has this security impact, why should he automatically believe you?

Er, because he found and wrote exploits for quite a few security problems in the kernel?

2.6.32.9 Release notes

Posted Feb 25, 2010 13:52 UTC (Thu) by vonbrand (guest, #4458) [Link]

Please stop this nonsense. If Linus (or whoever) knows about the possible security implications of, let's say, 10 or 20% of the bugs, and only marked those, the majority of security sensitive bug patches would just be ignored by would-be "experts", and the whining about the other "not reported" bugs would start whenever some box gets broken into...

A bug in the kernel is potentially extremely serious, go and fix it. Questions are optional, patching isn't.

2.6.32.9 Release notes

Posted Feb 25, 2010 14:55 UTC (Thu) by PaXTeam (guest, #24616) [Link]

> If Linus (or whoever) knows about the possible security implications of,
> let's say, 10 or 20% of the bugs, and only marked those the majority of
> security sensitive bug patches would just be ignored by would-be "experts"

stop that nonsense. you have zero evidence for it. in the previous thread a kernel developer only offered anecdotal evidence which is of course as good as mine or anyone else's. you might want to understand who patch users are too: http://lwn.net/Articles/374094/ . also you might want to explain why file system corruption bugs are marked as such in commit messages whereas there's no guarantee that unmarked commits don't fix file system corrupting bugs.

> A bug in the kernel is potentially extremely serious[...].

it depends on the bug. and as we learned from local experts here, it also depends on what one considers a bug at all ;).

> Questions are optional, patching isn't.

you've never really had a real job, have you.

2.6.32.9 Release notes

Posted Feb 25, 2010 20:44 UTC (Thu) by nix (subscriber, #2304) [Link]

Filesystem corruption bugs are marked as such *if people realise at fix
time that they are filesystem corruption bugs*.

Not all filesystem-corrupting bugs are recognised as such at fix time,
just like not all security bugs are recognised as such. (It is probably
easier to detect a filesystem-corrupting bug than a security bug, because
at least there are broad regions of the kernel where bugs are unlikely to
affect filesystems, which is not true for security holes.)

btw, nice to see you're vilely rude to everyone, not just me (and fifty
seconds' googling would make it clear that he's had multiple real jobs in
the free software community. He gives out his real name, you see.)

2.6.32.9 Release notes

Posted Feb 25, 2010 22:42 UTC (Thu) by PaXTeam (guest, #24616) [Link]

> *if people realise at fix time that they are filesystem corruption bugs*.

aha. and "if people realise at fix time that they are security bugs" they... don't mark them as such. not only that, they even try to explain why that's a good thing. now you tell me why the same arguments don't apply to filesystem corruption bugs (and many others, i just picked an obvious one for this exercise). or more to the point, why the arguments for marking known filesystem corruption bugs don't apply to known security bugs. btw, i'm glad that after years of misunderstanding you're slowly getting it ;).

> [...]because at least there are broad regions of the kernel where bugs
> are unlikely to affect filesystems,

anything that can result in kernel memory corruption, in those broad regions of the kernel included, has a fair chance to trash filesystem related (meta)data as well. speaking of which, by the same token if said memory corruption bugs are not marked for security, they should at least be marked for potential filesystem corruption but not even that is done.

> btw, nice to see you're vilely rude to everyone, not just me

i wasn't rude to you, you yourself admitted that you sometimes post under the influence of drugs that you later regret. i was merely wondering if the same happened here as well because you so obviously posted crap about something that wasn't ever said (you're welcome to prove your post with quotes from us).

> (and fifty seconds' googling would make it clear that he's had multiple
> real jobs in the free software community.

make it 5 seconds, but then we've got bigger skill differences i guess ;). and yes, i know where he teaches and it's also clear that he has no idea whatsoever about how a real corporation works where people have real responsibilities and the "Questions are optional, patching isn't" mentality doesn't fly in *any* production environment i've ever seen (hint: it's not how RH/Novell work either). but someone like you should know better than defending such a stand.

> He gives out his real name, you see.

this coming from an anonymous coward sounds just way too funny ;).

2.6.32.9 Release notes

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

aha. and "if people realise at fix time that they are security bugs" they... don't mark them as such.
And I agree that that is a bad thing, and have said so repeatedly, although I'd understand it if you were too busy sniping to actually read what I write.

2.6.32.9 Release notes

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

> It's not a straw man.

it is as none of us made such a claim you're trying to push here, in fact every time this comes up we make a claim to the contrary: kernel devs are not expected to figure out the security impact of bugs because they're not qualified to do so. just look at Jon's effort here and how he missed #1 and mischaracterized #2.

> I'm too lazy to look it up

you're not lazy to look it up, you're unable to but needed a convenient excuse.

> but nearly every time that there is a security problem in a kernel update

you're welcome to find a *single* post from us that makes a claim you wish to attribute to us. after all, if it was 'nearly every time' you won't have to spend more than a few seconds to find one.

> someone belly aches that the kernel developers should figure out for if this bug is a security problem for them.

we never made such a claim, and in fact i don't recall anyone else making it either. but the onus is on you to back up your statement.

> I didn't point anyone out explicitly, but it does appear that I hit a nerve.

considering the amount of trolling and shouting from you, i know whose nerve was hit ;).

2.6.32.9 Release notes

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

> It's not a straw man. I'm too lazy to look it up, but nearly every time that there is a security problem in a kernel update, someone belly aches that the kernel developers should figure out for if this bug is a security problem for them.

I certainly never asked for anything like that.

So, once again: if it is known, it should be passed on. That's it.

2.6.32.9 Release notes

Posted Feb 22, 2010 20:25 UTC (Mon) by clugstj (subscriber, #4020) [Link]

Guys, get over yourselves. When did I mention anyone by name?

2.6.32.9 Release notes

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

Just making sure that "someone" doesn't include me.

2.6.32.9 Release notes

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

if you weren't just trolling then you can name at least one of those 'whiners'. with actual proof of that whining to back it up of course. should be easy since "nearly every time that there is a security problem in a kernel update, someone belly aches that the kernel developers should figure out for if this bug is a security problem for them".

2.6.32.9 Release notes

Posted Feb 22, 2010 20:25 UTC (Mon) by jake (editor, #205) [Link]

> Apparently in the meantime Jake thought "it might not be very
> productive" and failed to inform us that he scrapped the idea.

(sorry for the late reply, I was travelling back from SCALE)

At around the same time as we were discussing the idea, there was a flamewar about the same subject going on in lkml and it seemed clear to me that the personalities involved (on both sides) would likely just perpetuate that. That's why I didn't think it would be very productive, fwiw.

But I certainly don't discourage information about the known security impacts of stable tree patches (or any other patches for that matter) being published. If it were, we would be likely to link to it.

jake

2.6.32.9 Release notes

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

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.

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 (guest, #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.

2.6.32.9 Release notes

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

> But I certainly don't discourage information about the known security
> impacts of stable tree patches (or any other patches for that matter)
> being published. If it were, we would be likely to link to it.

what form of disclosure would you link to? twitter? web forum? email archive?

2.6.32.9 Release notes

Posted Feb 22, 2010 21:48 UTC (Mon) by jake (editor, #205) [Link]

> what form of disclosure would you link to? twitter? web forum?
> email archive?

i think it would be difficult to link to individual twitter messages about each problem as it was noted (and i don't know that twitter gives enough room for context and such), but some kind of summary in a web forum or page, mailing list posting, or whatever would (obviously) be of interest to our readers.

jake

2.6.32.9 Release notes

Posted Feb 26, 2010 0:34 UTC (Fri) by malor (guest, #2973) [Link]

Nobody's asking for anything of the sort; what we want is very simple. If a bug is actively known to be a security issue, pass that information along instead of actively trying to obfuscate it.

2.6.32.9 Release notes

Posted Feb 23, 2010 0:08 UTC (Tue) by jimparis (guest, #38647) [Link]

Thanks for doing this. Even as a one-time thing, it gives a very useful idea of how prevalent security fixes are in these stable updates.

2.6.32.9 Release notes

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

It almost makes me wish for a microkernel... but, of course, all *that*
would do would be to convert a limited set of arbitrary code execution
holes into DoS attacks, introduce a pile of additional complexity that
would have holes of its own, and add a good bit of performance bashing.

What we really need is a better language. The surface for most of these
holes (null pointer dereference, integer and buffer overflow holes, at
least) could be reduced to that tiny subset of the kernel implemented in
assembler. Wire something like the pi calculus into the language and even
races would be automatically detectable. (Obviously we can't eliminate all
DoS attacks, ever, even with formally proven perfect hardware and an ideal
language. That class of holes will always be with us.)

But for better or worse Linux is written in C, dammit, so these holes will
keep on coming. Until we find a way to avoid all mistakes I don't see a
way to stop them, though sparse and friends can at least slow them down, a
bit. Blaming people for introducing holes when writing in a language like
this is like blaming people for tripping when walking backwards,
blindfolded, over rocky ground, in a blizzard, during an earthquake.

2.6.32.9 Release notes

Posted Feb 23, 2010 6:36 UTC (Tue) by error27 (subscriber, #8346) [Link]

Most of the security bugs listed here could have been found through static code checking. Our tools are not good enough yet, but in two years they will be.

2.6.32.9 Release notes

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

We have the notable advantage that the kernel is written in a stereotyped
subset of C (as is true of any program that's not written by a frothing
madman). So the tools can use that, and (as sparse and GCC do) can rely on
user annotations, as well as erring on the side of paranoia.

So, yes, I was being excessively depressing.

Process calculus... will not eliminate bugs

Posted Feb 24, 2010 3:28 UTC (Wed) by dps (guest, #5725) [Link]

I know quite a bit about process calculus, although my choice of poison is CSP. The concurrency workbench is CCS, if I remember correctly. FDR, which may be available to developers in academia, handles CSP. Do you know of anything similar for pi-calculus?

You could, of course, follow my PhD thesis and prove a general result about a class of systems and limit yourself to that class of system. You can even write frameworks which make it almost impossible to do anything else. (I could say more but wont.)

Unfortunately whatever you do there is the problem of arguing that the kernel code corresponds to the process calculus or has the things your general proof required.

99.98% of the time concurrency just adds locking and context switches and therefore reduces system performance. The best approach the other 0.02% of the time is a more difficult question.

Process calculus... will not eliminate bugs

Posted Feb 24, 2010 8:30 UTC (Wed) by nix (subscriber, #2304) [Link]

Unfortunately whatever you do there is the problem of arguing that the kernel code corresponds to the process calculus or has the things your general proof required.
Exactly. Without an automated prover the thing is mostly useless for actually reducing bug count: and when was the last time you encountered an automated prover for any but the most toy of languages that actually was automated? They tend to need so much assistance that they become far more a burden than a help, unless you're doing something hyper-life-critical.

I was musing on the theoretical bound when I should have been thinking about reality...

2.6.32.9 Release notes

Posted Feb 23, 2010 0:52 UTC (Tue) by ebiederm (subscriber, #35028) [Link]

I find it fascinating that chmod being broken on sysfs is not considered by this thread a security issue.

2.6.32.9 Release notes

Posted Feb 23, 2010 1:48 UTC (Tue) by spender (guest, #23067) [Link]

Yea I find it fascinating too that the code you wrote that introduced the bug was also fixed by you with a commit message missing the original details about chmod from the bug reporter (available here: http://lkml.org/lkml/2010/1/20/168) and mentioning "Resulting in overly restrictive permissions on sysfs files" yet apparently with the knowledge that it was a security issue wasn't picked up by a non-security person as a security issue.

Same goes for all those sysctl vulnerabilities you claimed before that weren't fixed by anything but your sysctl rewrite. I mean, those vulnerabilities should be utterly obvious to any backporter!

I'm simply shocked.

-Brad

2.6.32.9 Release notes

Posted Feb 23, 2010 11:16 UTC (Tue) by jebba (guest, #4439) [Link]

Thx for the detailed report Jon. :)

I personally appreciate what Spender/PaXteam do as well, and don't give a damn that their style may not be to everyone's taste. Who cares? "You left a wheel off the 747, it's going to crash!" "Oh! How can you be so rude?" Ridiculous.

That said, it would be fantastic if they could share their extensive knowledge more widely. What is preventing you guys from following up on LKMLish lists with info you appear to already have in hand? Perhaps if you called "BS" there for a number of months to individual commits a larger audience would see what was going on and things might change.

2.6.32.9 Release notes

Posted Feb 25, 2010 1:31 UTC (Thu) by motk (subscriber, #51120) [Link]

In this fine thread: The usual carpetbaggers whining and carping that they can't generate free lunches forever for themselves from security theatre.

Very flammable kernel you've got here, could go up like a firework with one negligently dropped pointer, know what I mean, squire?


Copyright © 2010, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds