Re: Should Linux VDSO be using symbol version based on the released kernel?

[Mike Frysinger <vapier at gentoo dot org>]

On 04 May 2016 15:22, Adhemerval Zanella wrote:
> On 04/05/2016 13:37, Carlos O'Donell wrote:
> > The Linux VDSO uses a singular version string, different by
> > architecture, for all VDSO symbols e.g. LINUX_2.6.29 for s390x.
> > 
> > Should the Linux kernel be using LINUX_4.5 as the version string
> > for new VDSO symbols added in LINUX_4.5?
> > 
> > That way we can talk sensibly about what VDSO symbols were added
> > upstream, and talk sensible about the ABI/API being exported by
> > any given kernel via the VDSO?
> > 
> > Right now the version is really only meaningless version for
> > future compat support.
> 
> Ideally I would say yes, however the way we use the vDSO is not
> by exporting it directly in GLIBC own supported versions, but 
> rather through wrappers and these already take care of check if
> the symbol exist based on exported kernel version.

logically it seems like the version symbol should match the version of
the kernel where it first showed up, but practically speaking i don't
think it matters.

> And I do not think we should think the vDSO as an stable ABI
> that we must enforce symbol version compatibility, but rather
> helper functions that GLIBC would use internally.

err, it should be a stable ABI in the sense that the func cannot break
behavior.  e.g. __vdso_getcpu@@LINUX_2.6 must behave the same way it
always has.  if you want to change the func API, then add a new symbol
version e.g. __vdso_getcpu@@LINUX_4.5.

> It is the same rationale based on other Linux exported facilities
> that we do support directly.

yes, the vDSO should be held to the same Linux stable ABI guarantees
as syscalls or /proc or /sys interfaces.  if code is using it (like
glibc), then it cannot be broken.  that includes dropping symbols if
userspace is making assumptions about its existence.  this might not
be a common issue with any one symbol since the ELF symbol versioning
has set up an expectation that userspace should check before using,
but since glibc has been dropping support for older kernels, it isn't
unreasonable for us to start blindly assuming for some arches/kernel
versions that (1) the vDSO always exists and (2) it always provides
certain functions.
-mike

Attachment: signature.asc
Description: Digital signature