Read the followup by pagexec [LWN.net]

Read the followup by pagexec

Posted Jun 9, 2011 18:50 UTC (Thu) by dlang (guest, #313)
In reply to: Read the followup by pagexec by ballombe
Parent article: Quotes of the week

but to get a CVE number you have to not only say you fixed a bug, but explain what that bug is and how it could be exploited.

frankly, if I'm fixing a bug I'm far less worried about figuring out ways that it could be exploited than I am in getting it fixed.

and I know that I would prefer to have the kernel hackers spend all their time fixing bugs (and implementing new features) rather than trying to figure out ways that bugs could be exploited.

to post comments

Read the followup by pagexec

Posted Jun 10, 2011 10:49 UTC (Fri) by mingo (subscriber, #31122) [Link] (16 responses)

Yes, there's also a fundamental problem: fixing bugs requires very concentrated attention - which narrows any thinking about what potential side-effects of a bug can have in practice.

Bug fixers are, very fundamentally, concentrated on understanding *one* specific symptom and then finding the bug, then going to the 'big picture' of the intent of the code and changing the code (and related code) into correct code which implements the original 'big picture' intent.

Note what is missing from those thought patterns: figuring out *other* obscure symptomatic ways to use unintended side-effects of the bug to bring some application (or the kernel) out of its intended path of execution and use that to inflict harm on the system ...

The bug fixer is simply not interested in it because that information is *immaterial* to him: he is interested in *fixing* the bug and then reviewing the rest of the logic to make sure it implements intent correctly.

So bug fixes, even by the best bug fixers, do not carry full information about whether some obscure side-effect of the bug may have some security impact.

Attackers on the other hand only deal with specific bugs and know the various patterns that are dangerous in terms of bringing apps off their regular execution pathways. They also know the various obscure side-effects that bugs can cause and which can be used creatively to elevate privileges. In essence attackers know how to turn existing structure against its own intended purpose, i.e. they know how to be *parasites*.

So this is a fundamental (almost genetic) conflict between 'doers' and 'parasites', and we cannot expect doers to think like parasites, and i argued in my mail that putting CVEs into change-logs only makes the situation worse, not better.

There might be other schemes that improve security - so this is not a refusal to do sensible things at all, it is a refusal to do nonsensical things.

Read the followup by pagexec

Posted Jun 11, 2011 13:14 UTC (Sat) by zakalwe2 (guest, #50472) [Link] (15 responses)

Kernel developers have no interest in the security aspect of bugs and therefore have little understanding or care of the potential impact. When the devastating impact of these bugs is revealed to them in the form of harsh language or working exploits, they gain a transient, whimsical interest in the problem and implement half-baked general solutions that degrade over time through code erosion and neglect. This pervasive attitude towards bugs seriously underestimates their impact, and in turn ensures that no real severity limiting features (exploit mitigation) is ever valued or implemented properly.

Read the followup by pagexec

Posted Jun 11, 2011 13:54 UTC (Sat) by mingo (subscriber, #31122) [Link] (14 responses)

I disagree, if you look at actual evidence you'll see that we kernel developers deeply care about bugs (regardless of whether they have security relevance or not), and fix them as quickly as we can.

We also have various bug mitigation facilities and are extending them continuously. The actual lkml thread where the quote came from is about such a security bug mitigation effort which is being merged into the kernel.

Read the followup by pagexec

Posted Jun 11, 2011 15:10 UTC (Sat) by nix (subscriber, #2304) [Link] (13 responses)

And your reward? Attacks and insults from the usual suspects because the proposed name of the config variable for the new feature is in their eyes wrong.

sigh.

Read the followup by pagexec

Posted Jun 11, 2011 16:13 UTC (Sat) by spender (guest, #23067) [Link] (12 responses)

By usual suspects do you mean Ingo and Linus? You know, since they were the ones who had the problem with the already-existing name.

-Brad

Read the followup by pagexec

Posted Jun 11, 2011 16:55 UTC (Sat) by mingo (subscriber, #31122) [Link] (11 responses)

FYI, pageexec objected to calling it COMPAT/LEGACY_VTIME and called that naming a "lie" and a "coverup".

So yes, the usual suspects are attacking and insulting us - and then in other forums they are denying that it ever happened.

Read the followup by pagexec

Posted Jun 11, 2011 17:08 UTC (Sat) by spender (guest, #23067) [Link] (10 responses)

Perhaps you might like to read further back in that thread, as it already contains the subject of renaming it from the initial proposed name, to a new name. Why did the name need to be changed? This may refresh your memory:

https://lkml.org/lkml/2011/6/6/94
Linus ^

https://lkml.org/lkml/2011/6/6/141
and you! ^

You see, the patch already had a name. That is what we would call "the proposed name" as it was the name given by the author of the patch. But with your view of security as a taboo subject that can't be discussed clearly, wanted the name changed despite the fact that the only reason for the change is for security reasons, which would make the old method "unsafe."

-Brad

Read the followup by pagexec

Posted Jun 11, 2011 17:42 UTC (Sat) by mingo (subscriber, #31122) [Link] (9 responses)

FYI, there were two naming discussions in the thread: first Linus disliked the proposed CONFIG_UNSAFE_VSYSCALLS name. Then pageexec disliked the CONFIG_COMPAT/LEGACY_VTIME proposed name and started insulting me.

Linus was actually right that the first name was misleading.

Read the followup by pagexec

Posted Jun 11, 2011 18:13 UTC (Sat) by spender (guest, #23067) [Link] (8 responses)

It's your opinion that he's right. Linus didn't want a random person to be "scared" by the name and turn it off, because then they might be subject to improved security and lower performance until they update their glibc. Of course, he didn't consider the other side of the coin, the same person who chooses not to read configuration help and enables/disables options based on their config name alone, doesn't disable this feature, even long after their glibc is updated. It's not black/white, right/wrong -- you preferred performance over security in this case. To say the original name was fine is perfectly acceptable.

BTW is it misleading to all those embedded users to have any mention of security when they don't have MMUs? They might get scared and turn features off! I urge you then to remove all mentions of security from your commit messages so they aren't mislead. Oh wait..

-Brad

Read the followup by pagexec

Posted Jun 11, 2011 18:34 UTC (Sat) by mingo (subscriber, #31122) [Link] (2 responses)

It's your opinion that he's right.

That the static vsyscall page is not a security vulnerability in itself is not just my opinion, it is a rather common-sense statement and it is our editor's opinion as well:

One useful point from that discussion is that the static vsyscall page is not, in fact, a security vulnerability; it's simply a resource which can make it easier for an attacker to exploit a vulnerability elsewhere in the system.

So could you guys please stop attacking people just because they disagree with you?

Read the followup by pagexec

Posted Jun 11, 2011 19:00 UTC (Sat) by spender (guest, #23067) [Link] (1 responses)

I agree it's not a security vulnerability because I understand the definition of vulnerability. We weren't discussing that, though, you just brought it up. What we *were* discussing was the "UNSAFE" name. "UNSAFE" is a perfectly accurate name for the option. If it's not "unsafe" then are you saying fixed-address vsyscall is safe? No, of course you wouldn't say that, that's the entire reason for the patch (read: security)!

So no, I'm not wrong because you brought in a strawman and put words in my mouth ;) BTW, I notice from on here and on LKML you often use appeals to authority as a means of making an argument. As the MIT example should show, it's generally a poor approach to use :)

Anyway, my point has been sufficiently made for the other readers here (as I see you won't ever concede your position). It's very telling really that possibly misleading a hypothetical user into lowering their performance in some cases is taken seriously, whereas misleading them into reducing their security (or rather, maintaining it at the same poor level), is not even discussed/acknowledged ;)

-Brad

Read the followup by pagexec

Posted Jun 11, 2011 20:18 UTC (Sat) by mingo (subscriber, #31122) [Link]

Well, you are language lawyering now.

Linus's and my opinion is that calling something 'unsafe' suggests that it's ... unsafe - while in reality the vsyscall itself is not unsafe: it needs a vulnerability to have any security role.

Read the followup by pagexec

Posted Jun 11, 2011 20:23 UTC (Sat) by Julie (guest, #66693) [Link] (4 responses)

he didn't consider the other side of the coin, the same person who chooses not to read configuration help and enables/disables options based on their config name alone, doesn't disable this feature...

If he didn't consider this maybe it was because he thought anyone config'ing their own kernel without checking the ---help--- is being at least a little silly.

I always build my own kernels and when I config one I feel it's only common sense to be expected to take some responsibility for the outcome myself, which means being able to work out (if I don't know) what does what, which implies checking the config help for new or unfamiliar features and not just making assumptions based on the name of the feature about what it is or does.
So I always check new config options, and if I didn't do this and I ended up disabling something I was relying on using or having some other unpleasant experience resulting from it well, that would be my own fault, wouldn't it. Because I shouldn't be messing with it in the first place. A really useful lesson in humility, at least...

I'm pretty sure distro and kernel maintainers and other users who have more at stake than me, or more of a measure of responsibility, check new configs too - isn't it just sensible?

CONFIG_UNSAFE_VSYSCALLS as a config name does seem rather histrionic though.

Read the followup by pagexec

Posted Jun 11, 2011 20:29 UTC (Sat) by mingo (subscriber, #31122) [Link] (2 responses)

LOL, histrionic indeed :-)

Note that the config option is gone in the patches i've applied days ago and which are queued up for mainline integration.

Read the followup by pagexec

Posted Jun 12, 2011 10:36 UTC (Sun) by patrick_g (subscriber, #44470) [Link] (1 responses)

>>> the config option is gone in the patches i've applied days ago and which are queued up for mainline integration

Mainline integration in 3.0 or for the next merge window (ie 3.1) ?

Read the followup by pagexec

Posted Jun 12, 2011 12:27 UTC (Sun) by mingo (subscriber, #31122) [Link]

Next merge window for now - the patches are too big and complex to be included in 3.0.

You can try them on 3.0 a well, via the -tip tree.

The patches are available standalone as well, see the tip/x86/vdso branch.

Read the followup by pagexec

Posted Jun 11, 2011 20:36 UTC (Sat) by spender (guest, #23067) [Link]

I was trying to illustrate that the same person who disables the option because they're "scared" by "UNSAFE" in the config name itself, apparently without reading the following config help:
+ Legacy user code expects to be able to issue three syscalls
+ by calling fixed addresses in kernel space. If you say N,
+ then the kernel traps and emulates these calls. If you say
+ Y, then there is actual executable code at a fixed address
+ to implement time() efficiently.
+
+ On a system with recent enough glibc (probably 2.14 or
+ newer) and no static binaries, you can say N without a
+ performance penalty to improve security
+
+ If unsure, say Y.

is the same kind of foolish user who would leave it on because it says "COMPAT" in the name and they don't want to break anything (even though disabling it doesn't break anything). So we're not in disagreement, I just didn't state it as clearly as I should have apparently.

-Brad