vdso主要用于快速系统调用，arm也支持。
如果需要频繁获取时间，每次都走常规系统调用，开销太大了。
用vdso，则可以在不做系统调用，不陷入内核的情况下获取系统时间。

本文转自
https://zhuanlan.zhihu.com/p/436454953
正文开始

在某些架构中，每当内核加载一个ELF可执行程序时，内核都会在其进程地址空间中建立一个叫做vDSO mapping的内存区域。

vDSO是virtual dynamic shared object的缩写，表示这段mapping实际包含的是一个ELF共享目标文件，也就是俗称的.so。

背景知识
快速系统调用之争
在x86-32系统大行其道的时代，调用系统调用的方法就是int $0x80。这种方法的执行速度非常慢，原因是它需要经历一个完整的中断处理过程，这包括Linux内核以及与中断流程相关的处理器微码的执行开销。

后来为了提升系统调用的性能，Intel最先实现了专门的快速系统调用指令sysenter和系统调用返回指令sysexit；后来AMD针锋相对地实现了另一组专门的快速系统调用指令syscall和系统调用返回指令sysret。

快速系统调用的“快”字，体现在以下几个方面：

处理器在切换到内核态后不再自动往内核栈中自动保存任何上下文信息了，这样避免了访内开销。
处理器也不再自动加载内核栈的值到rsp寄存器了，节省了指令开销。
syscall和sysret指令只能用在平坦内存模型中，因此在执行快速系统调用时bypass了MMU的分段单元的检查，节省了微码的执行开销。
处理器微码不再需要走中断处理和中断恢复流程，大幅度提高了执行性能。
与Intel的快速系统调用指令相比，AMD的syscall/sysret要更快更灵活：

执行syscall和sysret指令时，不再需要处理器自动保存和恢复用户栈指针了，因此也不需要再事先设置MSR来指定要恢复和保存的用户栈指针了。
通过系统调用进入内核态后，rflags寄存器中哪些位应该清0原本是固定的，但是如果是用syscall来执行系统调用的话，那这些位是可以通过编程来事先设置的。
最后，Intel也提供了对sysenter/sysexit指令的支持。之后，为了获得最好的兼容性（Intel和AMD通用），x86-64 Linux内核将快速系统调用的支持方式统一到了syscall/sysret。

题外话：Intel要求在内核启动阶段必须事先设置好IA32_EFER.SCE位才能在64位处理器模式中使用syscall和sysret指令，否则会触发#GP异常。

吐槽：死傲娇！64位处理器模式都是人家AMD先出的，你还在乎个指令？

从vsyscall说起
芯片厂商的争斗导致的结果就是libc和内核开发者需要对不同的快速系统调用指令进行适配，而且开发人员肯定希望用一种通用方案能够同时解决两家芯片厂商不同的快速系统调用实现方式。

在那段时间里，开发人员针对当时的x86系统开发了vsyscall机制，即glibc通过调用__kernel_vsyscall来确定到底应该执行syscall/sysret指令还是sysenter/sysexit指令。__kernel_vsyscall是一个特殊的页，其位于内核地址空间，但也是唯一允许用户访问的区域，该区域的地址固定为0xffffffffff600000（64位系统），大小固定为4K。由于所有的进程都共享内核映射，因此所有的进程也自然而言能够访问到vsyscall page。

此外，vsyscall还提供了另一个重要的作用：加速某些系统调用函数的执行效率。以gettimeofday()系统调用为例。该系统调用返回的结果起始并不涉及任何数据安全问题，因为特权用户root和非特权用户都会获得相同的结果。这就意味着其实完全可以通过新的实现机制来避免执行系统调用的开销，因为本质上gettimeofday()就是从内核中读取与时间相关的数据（虽然会有一些复杂的计算过程）。与其费尽心力一定要通过陷入内核的方式来读取这些数据，不如在内核与用户态之间建立一段共享内存区域，由内核定期“推送”最新值到该共享内存区域，然后用户态程序在调用这些系统调用的glibc库函数的时候，库函数并不真正执行系统调用，而是通过vsyscall page来读取该数据的最新值，相当于将系统调用改造成了函数调用，直接提升了执行性能。vsyscall机制支持的系统调用有3个：

gettimeofday()
time()
getcpu()
从glibc提供的头文件/usr/include/asm/vsyscall.h中就可以看出vsyscall page的用法了：

ifndef _ASM_X86_VSYSCALL_H

define _ASM_X86_VSYSCALL_H

enum vsyscall_num {
__NR_vgettimeofday,
__NR_vtime,
__NR_vgetcpu,
};

define VSYSCALL_START (-10UL << 20)

define VSYSCALL_SIZE 1024

define VSYSCALL_END (-2UL << 20)

define VSYSCALL_MAPPED_PAGES 1

define VSYSCALL_ADDR(vsyscall_nr) (VSYSCALL_START+VSYSCALL_SIZE*(vsyscall_nr))

endif /* _ASM_X86_VSYSCALL_H */

但由于一些原因，开发人员又抛弃了vsyscall机制：

vsyscall的映射地址是固定不变的（从vsyscall.h的定义就可以看出），因此很容易成为ret2libc攻击的跳板。
vsyscall能支持的系统调用数有限，无法很方便地进行扩展。
虽然开发人员在x86-64上实现了emulated vsyscall机制，同时借助vvar mapping在一定程度上缓解了第一个问题，但执行性能上不如vsyscall native模式。于是开发人员设计了vDSO机制来取代vsyscall，同时必须克服vsyscall的所有缺点。

...