Re: [PATCH] x86-64, vsyscalls: Rename UNSAFE_VSYSCALLS to COMPAT_VSYSCALLS

[pageexec@freemail.hu]

On 9 Jun 2011 at 9:02, Ingo Molnar wrote:

> * pageexec@freemail.hu <pageexec@freemail.hu> wrote:
> > so can i take it as your concession that the vsyscall feature is 
> > indeed a security problem and it's being randomized/(re)moved for 
> > security reasons?
> 
> Again, i made two statements:
> 
>   "That naming is borderline security FUD"
>   "It's only a security problem if there's a security hole elsewhere."
> 
> I stand by those statements and i reject your repeated attempts to 
> put words in my mouth that i did not say, such as:
> 
>    > you called this feature "borderline security FUD" [...]

it's no more putting words into your mouth than your own attempt:

> You generally seem to assume that security is an absolute goal 
> with no costs attached.

(for which i'm still waiting for an actual proof btw ;)

also, notice i didn't quote you ("..." or >... style), i simply paraphrased
what you said and explained why. i got no response to those arguments though
so i guess you conceded them. then why do you keep arguing the same nonsense?

> > how can the name be "borderline security FUD" but what the name 
> > refers to not be that? you see, we name things for a reason, mostly 
> > because we think the name has something to do with the thing it 
> > names, duh?
> 
> It's borderline security FUD because it suggests that keeping the 
> vsyscall around is in itself a security hole.

it's not a hole per se, rather it's an accessory to writing reliable
exploits (not only userland ones btw). that's the *only* reason this
patchset even exists. do you deny that? now, if you don't deny it then
you also agree that the current vsyscall page *is* a security problem
(problem != hole). therefore the suggested name for the config option
that removes it for good cannot be "borderline security FUD".

> As i outlined whether there's *another* bug that *can be exploited* is
> highly dependent on the usecase - while the Kconfig name made no such
> distinction. (For example a device maker might choose to keep the
> option enabled in some embedded usecase, those are pretty limited
> environments that have few vectors of attack.) 

but you see, your own argument defeats your point: if for another use
case the presence of the vsyscall page *is* a security hazard (like,
i don't know, every single server and desktop out there?) then *not*
making it clear in the option name *is* a problem. see how it cuts
both ways? what now? ;) prudent people err on the side of safety.

also if the above device maker disables it even if their devices would
never ever be exploited using the vsyscall page, they haven't lost anything.
heck, they'll have reduced their kernel image and gained some all too
important cycles ;).

> Anyway, repeating and explaining my arguments a dozen times

repeated - yes, explained - no, that's the problem. you didn't even address
what *i* said (how many questions of mine have you left unanswered?). i'm
guessing because you realized how wrong you were but you're not the kind of
person who'd admit it.

> did not make any difference to you, and there's a point where i have
> to stop wasting time on a person, so i've started filtering out your
> mails. If you want to send me any patches then please send it to any
> of my co-maintainers who will be able to review them. 

PS: thanks for the cycles^Wchuckles ;)