我做了 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 是内存的内核部分吗？如果有人能对这个问题有所了解，那就太好了。

最佳答案

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，则会进行传统的系统调用。

学分和有用的链接:

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

https://stackoverflow.com/questions/19938324/