Giu*_*Pes 4 x86 system-calls linux-kernel
我试图理解Linux用来调用系统调用的机制.特别是,我正在努力理解VSDO机制.它可以用于调用所有系统调用吗？vsdo页面和进程内存中的vsyscall页面有什么区别？他们总是在那里吗？
例如使用cat/proc/self/maps:
7fff32938000-7fff32939000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
最好,
该vsyscall和VDSO段用于加速Linux的某些系统调用的机制.例如,gettimeoftheday通常通过此机制调用.引入的第一个机制是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支持,则会进行传统的系统调用.
积分和有用的链接: