什么是vdso和vsyscall？(What are vdso and vsyscall?)

我做了sudo cat /proc/1/maps -vv

我试图理解输出。我可以看到许多共享库被映射到内存映射段，如预期的那样。

7f3c00137000-7f3c00179000 r-xp 00000000 08:01 21233923 /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8 7f3c00179000-7f3c00379000 ---p 00042000 08:01 21233923 /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8 7f3c00379000-7f3c0037a000 r--p 00042000 08:01 21233923 /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8 7f3c0037a000-7f3c0037b000 rw-p 00043000 08:01 21233923 /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8 7f3c0037b000-7f3c00383000 r-xp 00000000 08:01 21237216 /lib/x86_64-linux-gnu/libnih-dbus.so.1.0.0 7f3c00383000-7f3c00583000 ---p 00008000 08:01 21237216 /lib/x86_64-linux-gnu/libnih-dbus.so.1.0.0 7f3c00583000-7f3c00584000 r--p 00008000 08:01 21237216 /lib/x86_64-linux-gnu/libnih-dbus.so.1.0.0 7f3c00584000-7f3c00585000 rw-p 00009000 08:01 21237216 /lib/x86_64-linux-gnu/libnih-dbus.so.1.0.0 7f3c00585000-7f3c0059b000 r-xp 00000000 08:01 21237220 /lib/x86_64-linux-gnu/libnih.so.1.0.0 7f3c0059b000-7f3c0079b000 ---p 00016000 08:01 21237220 /lib/x86_64-linux-gnu/libnih.so.1.0.0 7f3c0079b000-7f3c0079c000 r--p 00016000 08:01 21237220 /lib/x86_64-linux-gnu/libnih.so.1.0.0

到最后有一些像

7f3c0165b000-7f3c0177e000 rw-p 00000000 00:00 0 [heap] 7fff97863000-7fff97884000 rw-p 00000000 00:00 0 [stack] 7fff97945000-7fff97946000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]

vdso和vsyscall是什么意思？是vsyscall内存部分的内存？如果有人可以在这个问题上提出一些看法，那将是巨大的。

I did sudo cat /proc/1/maps -vv

I am attempting to make sense of the output.I can see a lot of shared libraries being mapped to the memory mapping segment as expected.

7f3c00137000-7f3c00179000 r-xp 00000000 08:01 21233923 /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8 7f3c00179000-7f3c00379000 ---p 00042000 08:01 21233923 /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8 7f3c00379000-7f3c0037a000 r--p 00042000 08:01 21233923 /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8 7f3c0037a000-7f3c0037b000 rw-p 00043000 08:01 21233923 /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8 7f3c0037b000-7f3c00383000 r-xp 00000000 08:01 21237216 /lib/x86_64-linux-gnu/libnih-dbus.so.1.0.0 7f3c00383000-7f3c00583000 ---p 00008000 08:01 21237216 /lib/x86_64-linux-gnu/libnih-dbus.so.1.0.0 7f3c00583000-7f3c00584000 r--p 00008000 08:01 21237216 /lib/x86_64-linux-gnu/libnih-dbus.so.1.0.0 7f3c00584000-7f3c00585000 rw-p 00009000 08:01 21237216 /lib/x86_64-linux-gnu/libnih-dbus.so.1.0.0 7f3c00585000-7f3c0059b000 r-xp 00000000 08:01 21237220 /lib/x86_64-linux-gnu/libnih.so.1.0.0 7f3c0059b000-7f3c0079b000 ---p 00016000 08:01 21237220 /lib/x86_64-linux-gnu/libnih.so.1.0.0 7f3c0079b000-7f3c0079c000 r--p 00016000 08:01 21237220 /lib/x86_64-linux-gnu/libnih.so.1.0.0

Towards the end there is something like

7f3c0165b000-7f3c0177e000 rw-p 00000000 00:00 0 [heap] 7fff97863000-7fff97884000 rw-p 00000000 00:00 0 [stack] 7fff97945000-7fff97946000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]

What does vdso and vsyscall mean? is vsyscall the kernel portion of the memory? It would be great if anyone can throw some light on the issue.

最满意答案

vsyscall和vDSO段是用于加速Linux中某些系统调用的两种机制。例如，通常通过这种机制来调用gettimeofday 。引入的第一个机制是vsyscall ，它被添加为一种执行特定系统调用的方式，不需要任何真正的权限级别来运行，以减少系统调用开销。遵循前面的例子，所有gettimeofday需要做的是读取内核的当前时间。有些应用程序可以频繁地调用gettimeofday （例如生成时间戳），直到他们关心甚至一点点开销。为了解决这个问题，内核将映射到用户空间中，包含当前时间和快速gettimeofday实现的页面（即只读取保存在vsyscall中的时间的函数）。使用这个虚拟系统调用，C库可以提供一个快速的gettimeofday ，它不具有由内核空间和通常由经典系统调用模型INT 0x80或SYSCALL引入的用户空间之间的上下文切换引入的开销。

然而，这个vsyscall机制有一些局限性：分配的内存很小，只允许4个系统调用，更重要和更严重的是，在每个进程中， vsyscall页被静态地分配到同一个地址，因为vsyscall页面的位置是钉在内核ABI中。 vsyscall的这种静态分配会损害由Linux常用的内存空间随机化引入的好处。攻击者在利用堆栈溢出危害应用程序之后，可以使用任意参数从vsyscall页面调用系统调用。所有他需要的是系统调用的地址，这是很容易预测的，因为它是静态分配的（如果你尝试再次运行你的命令，即使使用不同的应用程序，你会注意到， vsyscall的地址不会改变）。最好删除或至少随机选择vsyscall页面的位置来阻止这种类型的攻击。不幸的是，应用程序取决于该页面的存在和确切地址，因此无法完成任何操作。

通过特殊的陷阱指令替换固定地址处的所有系统调用指令来解决这个安全问题。尝试调用到vsyscall页面的应用程序将陷入内核，然后它将在内核空间中模拟所需的虚拟系统调用。结果是模拟虚拟系统调用的内核系统调用，该调用放在那里以避免内核系统调用。结果是一个vsyscall需要更长的执行时间，但最重要的是不会破坏现有的ABI。无论如何，只有当应用程序尝试使用vsyscall页面而不是vDSO时才会看到这个减速。

vDSO提供与vsyscall相同的功能，同时克服其限制。 vDSO（虚拟动态链接共享对象）是在用户空间中分配的内存区域，以安全的方式在用户空间中公开一些内核功能。这是为了解决由vsyscall引起的安全威胁。 vDSO是动态分配的，可以解决安全问题，可以有超过4个系统调用。 vDSO链接通过glibc库提供。链接器将链接glibc vDSO功能，前提是这样的例程有一个附带的vDSO版本，如gettimeofday 。当您的程序执行时，如果您的内核没有vDSO支持，将会传统的系统调用。

积分和有用的链接：

令人敬畏的教程，如何创建自己的vDSO 。 vsyscall和vDSO，很好的文章有用的文章和链接什么是linux-gate.so.1？

The vsyscall and vDSO segments are two mechanisms used to accelerate certain system calls in Linux. For instance, gettimeofday is usually invoked through this mechanism. The first mechanism introduced was vsyscall, which was added as a way to execute specific system calls which do not need any real level of privilege to run in order to reduce the system call overhead. Following the previous example, all gettimeofday needs to do is to read the kernel's the current time. There are applications that call gettimeofday frequently (e.g to generate timestamps), to the point that they care about even a little bit of overhead. To address this concern, the kernel maps into user space a page containing the current time and a fast gettimeofday implementation (i.e. just a function which reads the time saved into vsyscall). Using this virtual system call, the C library can provide a fast gettimeofday which does not have the overhead introduced by the context switch between kernel space and user space usually introduced by the classic system call model INT 0x80 or SYSCALL.

However, this vsyscall mechanism has some limitations: the memory allocated is small and allows only 4 system calls, and, more important and serious, the vsyscall page is statically allocated to the same address in each process, since the location of the vsyscall page is nailed down in the kernel ABI. This static allocation of the vsyscall compromises the benefit introduced by the memory space randomisation commonly used by Linux. An attacker, after compromising an application by exploiting a stack-overflow, can invoke a system call from the vsyscall page with arbitrary parameters. All he needs is the address of the system call, which is easily predicable as it is statically allocated (if you try to run again your command even with different applications, you'll notice that the address of the vsyscall does not change). It would be nice to remove or at least randomize the location of the vsyscall page to thwart this type of attack. Unfortunately, applications depend on the existence and exact address of that page, so nothing can be done.

This security issue has been addressed by replacing all system call instructions at fixed addresses by a special trap instruction. An application trying to call into the vsyscall page will trap into the kernel, which will then emulate the desired virtual system call in kernel space. The result is a kernel system call emulating a virtual system call which was put there to avoid the kernel system call in the first place. The result is a vsyscall which takes longer to execute but, crucially, does not break the existing ABI. In any case, the slowdown will only be seen if the application is trying to use the vsyscall page instead of the vDSO.

The vDSO offers the same functionality as the vsyscall, while overcoming its limitations. The vDSO (Virtual Dynamically linked Shared Objects) is a memory area allocated in user space which exposes some kernel functionalities at user space in a safe manner. This has been introduced to solve the security threats caused by the vsyscall. The vDSO is dynamically allocated which solves security concerns and can have more than 4 system calls. The vDSO links are provided via the glibc library. The linker will link in the glibc vDSO functionality, provided that such a routine has an accompanying vDSO version, such as gettimeofday. When your program executes, if your kernel does not have vDSO support, a traditional syscall will be made.

Credits and useful links :

Awesome tutorial, how to create your own vDSO. vsyscall and vDSO, nice article useful article and links What is linux-gate.so.1?

更多推荐