什么是 vdso 和 vsyscall? [英] What are vdso and vsyscall?

查看:28
本文介绍了什么是 vdso 和 vsyscall?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我做了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

接近尾声

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]

vdsovsyscall 是什么意思?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.

推荐答案

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

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 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.

但是,这种vsyscall机制有一些局限性:分配的内存很小,只允许4个系统调用,而且更重要和严重的是,vsyscall页面是静态的在每个进程中分配到相同的地址,因为 vsyscall 页面的位置被确定在内核 ABI 中.vsyscall 的这种静态分配损害了 Linux 常用的内存空间随机化带来的好处.攻击者在利用堆栈溢出危害应用程序后,可以使用任意参数从 vsyscall 页面调用系统调用.他所需要的只是系统调用的地址,因为它是静态分配的,所以很容易预测(如果您尝试再次运行您的命令,即使使用不同的应用程序,您会注意到 vsyscall 不变).最好删除或至少随机化 vsyscall 页面的位置以阻止此类攻击.不幸的是,应用程序依赖于该页面的存在和确切地址,因此无能为力.

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 predictable 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.

此安全问题已通过用特殊陷阱指令替换固定地址处的所有系统调用指令得到解决.尝试调用 vsyscall 页面的应用程序将陷入内核,然后内核将在内核空间中模拟所需的虚拟系统调用.结果是一个内核系统调用模拟了一个虚拟系统调用,它被放在那里首先是为了避免内核系统调用.结果是 vsyscall 需要更长的时间来执行,但至关重要的是,它不会破坏现有的 ABI.在任何情况下,只有当应用程序尝试使用 vsyscall 页面而不是 vDSO 时才会看到速度变慢.

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.

vDSO 提供与 vsyscall 相同的功能,同时克服了其局限性.vDSO(虚拟动态链接共享对象)是在用户空间分配的内存区域,它以安全的方式在用户空间公开一些内核功能.引入这个是为了解决vsyscall引起的安全威胁.vDSO 是动态分配的,解决了安全问题,并且可以有 4 个以上的系统调用.vDSO 链接是通过 glibc 库提供的.链接器将链接 glibc vDSO 功能,前提是此类例程具有随附的 vDSO 版本,例如 gettimeofday.当您的程序执行时,如果您的内核没有 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.

积分和有用的链接:

这篇关于什么是 vdso 和 vsyscall?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆