Read the followup by pagexec [LWN.net]

Read the followup by pagexec

Posted Jun 11, 2011 15:10 UTC (Sat) by nix (subscriber, #2304)
In reply to: Read the followup by pagexec by mingo
Parent article: Quotes of the week

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.

to post comments

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