Messages in this thread | | | Date | Mon, 6 Jun 2011 14:47:43 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH] x86-64, vsyscalls: Rename UNSAFE_VSYSCALLS to COMPAT_VSYSCALLS |
| |
* pageexec@freemail.hu <pageexec@freemail.hu> wrote:
> On 6 Jun 2011 at 12:24, Ingo Molnar wrote: > > > > > * Linus Torvalds <torvalds@linux-foundation.org> wrote: > > > > > On Mon, Jun 6, 2011 at 2:50 AM, Andy Lutomirski <luto@mit.edu> wrote: > > > > CONFIG_UNSAFE_VSYSCALLS was added in the previous patch as a > > > > temporary hack to avoid penalizing users who don't build glibc from > > > > git. > > > > > > I really hate that name. > > > > > > Do you have *any* reason to call this "unsafe"? > > > > No, there's no reason at all for that. That naming is borderline > > security FUD and last time i saw the series i considered renaming > > it but got distracted :-) > > security FUD? for real? ;) [...]
'Borderline' security FUD! :-)
> [...] does that mean that you guys would accept a patch that would > map the vdso at a fixed address for old times's sake? if not, on > what grounds would you refuse it? see, you can't have it both ways.
You can actually do that by enabling CONFIG_COMPAT_VDSO=y.
> the fixed address of the vsyscall page *is* a very real security > problem, it should have never been accepted as such and it's high > time it went away finally in 2011AD.
It's only a security problem if there's a security hole elsewhere.
The thing is, and i'm not sure whether you realize or recognize it, but these measures *are* two-edged swords.
Yes, the upside is that they reduce the risks associated with security holes - but only statistically so.
The downside is that having such a measure in place makes it somewhat less likely that those bugs will be found and fixed in the future: if a bug is not exploitable then people like Spender wont spend time exploiting and making a big deal out of them, right?
And yes, it might be embarrasing to see easy exploits and we might roll eyes at the associated self-promotion circus but it will be one more bug found, the reasons for the bug will be examined, potentially avoiding a whole class of similar bugs *for sure*.
Can you guarantee that security bugs will be found and fixed with the same kind of intensity even if we make their exploitation (much) harder? I don't think you can make such a guarantee.
So as long as we are trading bugs-fixed-for-sure against statistical safety we have to be mindful of the downsides of such a tradeoff ...
Thanks,
Ingo
| |