> The .so file is installed on the file system like any other library.
Nope, it is built into the kernel image - at least on my system, but there doesn't seem to be a config option to disable that.
> When mapped into the process address space, it's just a normal ELF image. The functions all conform to the normal C ABI for the platform.
That's purely for convencience because it allows ASLR for the vDSO and there is no point in making it a new ad-hoc format if every C library already needs an ELF dynamic linker - if the vDSO was a thing before ELF it would surely have a different format.
> We do need to manually link the vDSO functions though: the kernel uses the auxiliary vector to pass the address of the vDSO ELF image to the process, allowing it to parse the ELF header and find the addresses of the functions. In most cases, the libc will do this while initializing itself prior to calling main.
You need to look up the entry points in the vDSO before you can call them but that is really no different than checking the kernel version before deciding which syscalls to invoke. And no, the vDSO is not loaded like any other .so - it is very much a special case [0] even if the libc ends up reusing some of the normal .so code and structures. For example, it needs to be loaded even for statically linked binaries [1].
Nope, it is built into the kernel image - at least on my system, but there doesn't seem to be a config option to disable that.
> When mapped into the process address space, it's just a normal ELF image. The functions all conform to the normal C ABI for the platform.
That's purely for convencience because it allows ASLR for the vDSO and there is no point in making it a new ad-hoc format if every C library already needs an ELF dynamic linker - if the vDSO was a thing before ELF it would surely have a different format.
> We do need to manually link the vDSO functions though: the kernel uses the auxiliary vector to pass the address of the vDSO ELF image to the process, allowing it to parse the ELF header and find the addresses of the functions. In most cases, the libc will do this while initializing itself prior to calling main.
You need to look up the entry points in the vDSO before you can call them but that is really no different than checking the kernel version before deciding which syscalls to invoke. And no, the vDSO is not loaded like any other .so - it is very much a special case [0] even if the libc ends up reusing some of the normal .so code and structures. For example, it needs to be loaded even for statically linked binaries [1].
[0] https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/sys...
[1] https://sourceware.org/git/?p=glibc.git;a=commit;h=1e8bdc3a2...