Messages in this thread |  | | | From | Andrew Lutomirski <> | | Date | Tue, 31 May 2011 14:59:10 -0400 | | Subject | Re: [PATCH v4 10/10] x86-64: Add CONFIG_UNSAFE_VSYSCALLS to feature-removal-schedule |
| |
On Tue, May 31, 2011 at 2:34 PM, Andi Kleen <andi@firstfloor.org> wrote: >> +What: CONFIG_UNSAFE_VSYSCALLS (x86_64) >> +When: When glibc 2.14 or newer is ubitquitous. Perhaps mid-2012. >> +Why: Having user-executable code at a fixed address is a security problem. >> + Turning off CONFIG_UNSAFE_VSYSCALLS mostly removes the risk but will >> + make the time() function slower on glibc versions 2.13 and below. > > I disagree with this description (and the whole idea really) > > First it's time+gettimeofday+vgetcu, not just time. > > A more accurate description is > > "will make all x86-64 Linux programs written to the original pre > vDSO syscall ABI significantly slower"
Well, if this series goes in, then gettimeofday and getcpu are already slower. It's just time that would get even slower later on.
> > And the assumption that all world is using glibc is still as bad > as it was on the first po.st
As opposed to?
uclibc and klibc don't appear to use vsyscalls or the vdso.
dietlibc is hardcoded to use the vsyscall. Are there any performance-critical programs using dietlibc?
I don't think that Bionic runs on any released x86-64 systems.
> > And it's still a bad idea. Especially since there's a much better > alternative anyways for the "security problem" which has none of > these drawbacks.
What's the alternative?
--Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |