Re: [PATCH v2] x86: Remove compat vdso support

[Andy Lutomirski]

On Mar 11, 2014 2:36 AM, "Linus Torvalds" <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> On Mon, Mar 10, 2014 at 9:10 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote:
> >
> > I suspect that a lot of 32-bit Linux users want syscall and/or
> > sysenter, and Stefani certainly wants the fast timing that the vDSO
> > can provide.  Also, presumably __kernel_sigreturn serves some purpose
> > :)
>
> Are we talking about the same thing at all?
>
> We're talking about the *COMPAT* vdso, right?
>
> The one you were just told Fedora had never _ever_ enabled? And you
> are seriously arguing that "peformance" is relevant, while at the same
> time trying to claim that the fact that it DOES NOT WORK on SuSE -
> which *did* enable it - is not such a big deal, and that we should
> ignore the "don't break user space" rule?

There isn't a separate "compat" vdso.  There may or may not be a vdso,
and that vdso may or may not be "compat".  Since the kernel can't
easily tell whether ld.so has the bug, the kernel can't easily decide
which vdso to present, if any.  So current kernels use only the compat
vdso by default.

The compat vdso *does* work on opensuse 9.  I'm arguing the the number
of people who use opensuse 9 is low enough that we should support them
by offering to turn off the vdso instead of by offering to fudge the
address at which the vdso is mapped.  The compat vdso also works on
modern glibc, but that comes at the expense of ASLR, some fixmap
entries that no one likes, and general maintainability of the code.


I wonder if we can actually detect buggy glibc versions at runtime.
The relevant commits are:

f866314b89d56845f55e6f365e18b31ec978ec3a: (Sun May 4 04:30:13 2003
+0000): add vdso support
3b3ddb4f7db98ec9e912ccdf54d35df4aa30e04a (Thu Feb 26 20:06:58 2004
+0000): remove the buggy assertion
49ad572a70b8aeb91e57483a11dd1b77e31c4468 (Sat Feb 28 17:56:22 2004
+0000): actually fix the code

Unfortunately, I was wrong about the affected versions.  Glibc 2.3.3
was released with the bug; glibc 2.3.2 and 2.3.4 appear to be okay.

It's okay for a quirk to incorrectly flag older glibc versions -- they
won't use a vdso regardless of what aux entries we set.  Incorrectly
flagging versions that are too new as quirky is unfortunate.

Checking for the text "(void *) ph->p_vaddr ==
_rtld_local._dl_sysinfo_dso" in ld.so will detect all but two days
worth of bad glibc versions.  I don't think that we actually want to
fault in the whole ELF loader on each program load, though.

We can detect glibc 2.3 in general by checking the symbol version
definitions.  That will incorrectly penalize a large range of later
versions, though.

We could do something really weird: we could look at the *name* of the
ELF loader.  This would have to resolve symlinks, which is rather ugly
and probably a net loss of sanity.


--Andy

>
> Seriously?
>
> WTF?
>
>                 Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/