1*98eedc3aSAndy LutomirskiOn some architectures, when the kernel loads any userspace program it 2*98eedc3aSAndy Lutomirskimaps an ELF DSO into that program's address space. This DSO is called 3*98eedc3aSAndy Lutomirskithe vDSO and it often contains useful and highly-optimized alternatives 4*98eedc3aSAndy Lutomirskito real syscalls. 5*98eedc3aSAndy Lutomirski 6*98eedc3aSAndy LutomirskiThese functions are called just like ordinary C function according to 7*98eedc3aSAndy Lutomirskiyour platform's ABI. Call them from a sensible context. (For example, 8*98eedc3aSAndy Lutomirskiif you set CS on x86 to something strange, the vDSO functions are 9*98eedc3aSAndy Lutomirskiwithin their rights to crash.) In addition, if you pass a bad 10*98eedc3aSAndy Lutomirskipointer to a vDSO function, you might get SIGSEGV instead of -EFAULT. 11*98eedc3aSAndy Lutomirski 12*98eedc3aSAndy LutomirskiTo find the DSO, parse the auxiliary vector passed to the program's 13*98eedc3aSAndy Lutomirskientry point. The AT_SYSINFO_EHDR entry will point to the vDSO. 14*98eedc3aSAndy Lutomirski 15*98eedc3aSAndy LutomirskiThe vDSO uses symbol versioning; whenever you request a symbol from the 16*98eedc3aSAndy LutomirskivDSO, specify the version you are expecting. 17*98eedc3aSAndy Lutomirski 18*98eedc3aSAndy LutomirskiPrograms that dynamically link to glibc will use the vDSO automatically. 19*98eedc3aSAndy LutomirskiOtherwise, you can use the reference parser in Documentation/vDSO/parse_vdso.c. 20*98eedc3aSAndy Lutomirski 21*98eedc3aSAndy LutomirskiUnless otherwise noted, the set of symbols with any given version and the 22*98eedc3aSAndy LutomirskiABI of those symbols is considered stable. It may vary across architectures, 23*98eedc3aSAndy Lutomirskithough. 24*98eedc3aSAndy Lutomirski 25*98eedc3aSAndy Lutomirski(As of this writing, this ABI documentation as been confirmed for x86_64. 26*98eedc3aSAndy Lutomirski The maintainers of the other vDSO-using architectures should confirm 27*98eedc3aSAndy Lutomirski that it is correct for their architecture.)