Re: [PATCH 3/4] Add 32 bit VDSO time support for 32 bit kernel

Roland McGrath
2014-02-03T21:12:01Z

> > config COMPAT_VDSO
> > def_bool y
> > prompt "Compat VDSO support"
> > depends on X86_32 || IA32_EMULATION
> > ---help---
> > Map the 32-bit VDSO to the predictable old-style address too.
> >
> > Say N here if you are running a sufficiently recent glibc
> > version (2.3.3 or later), to remove the high-mapped
> > VDSO mapping and to exclusively use the randomized VDSO.
> >
> > If unsure, say Y.
>
> So we need this for 32-bit glibc < 2.3.3, and we effecively have the
> same problem as on 64 bits. Next question is if those old glibcs rely
> on the entry point alone or if they also expect the vdso header at that
> address.
>
> I looked at the glibc diffs from 2.3.2 to 2.3.3, but it isn't really
> obvious to me what assumptions the 2.3.2 glibc made. Perhaps Roland has
> any idea?

Jakub often has more reliable memories of these things than I do.

>From looking at the old states of the code, AFAICT 2.3.3 was the first
version that actually looked at AT_SYSINFO_EHDR or cared about the vDSO per
se; 2.3.2 just uses AT_SYSINFO.

I have a vague recollection that there was a period wherein ld.so would
crash (trying to modify part of the read-only vDSO image in place) if the
vDSO was loaded somewhere other than its prelinked location. But I don't
see any evidence in the code that there was actually a release made of code
with that issue.

I'm fairly sure there are some relevant issues that I've forgotten and am
overlooking now.

> The safest thing for that might be to have the compat vdso be a
> completely separate object from the real vdso, and let the former be an
> object as similar to the current one as possible.

I'm not at all clear on what particular dangers that avoids.

Thanks,
Roland