【ostep】03 虚拟化 CPU - 受限直接执行机制

受限直接执行

我们已经学习了进程这个抽象概念,下面要接触到具体的机制了,之前说过,机制是某个功能的实现细节,而策略则类似于对机制的调度。

要学习的第一个机制被称为受限直接执行(Limited Direct Execution)

作为一个优秀的操作系统,应该小心地提供那些会导致危险的指令(例如对硬盘的 IO 操作,称特权指令),这些操作被操作系统封装为系统调用(system call)

但是这里还有一个问题,系统调用终究也是一长串指令序列,看起来它与用户的程序并无不同。毕竟 CPU 执行指令时也不会考虑这个指令是谁的。况且这个"谁"也只是我们的抽象罢了,进程(或者说程序)并无生命,在硬件层面根本不存在进程这一说,它们仅仅是内存中待执行的指令数据而已。

那么操作系统该怎么保护特权指令呢?当用户程序调用了特权指令会如何呢?

内核模式和用户模式

现代 CPU 拥有多级指令执行级别,即在不同级别下可以执行特定级别的指令,这些级别可以分为两种模式:内核模式(kernel mode)用户模式(user mode)

这些执行级别是通过硬件实现的,CPU 会检查特定寄存器中的值来确定当前的执行级别,这些逻辑都被设计在硬件中。

当机器启动时,引导程序会加载操作系统,此时操作系统运行在内核模式,从此往后,任何用户程序在什么执行级别下运行,完全由操作系统说了算。

就像人类社会的统治阶层,若他们不让民众使用特权,民众就永远没有机会成为统治阶层。换言之,任何在内核模式运行的程序都有机会将自己变成统治阶层。这让我想起了联合国五常的一票否决权,只有在五常自身同意的情况下,其他国家才能废除五常的一票否决权,否则其他国家就没有任何机会,因为五常可以直接一票否决"废除一票否决权"的提案。

这就是所谓"受限直接执行"的"受限"的含义。

回答第二个问题,当用户程序调用了特权指令会如何呢?

一般来说,当某进程的某个指令并不匹配目前的执行级别时,CPU 会异常,这时候操作系统可能会选择终止该进程。

这里的理解可以参考知乎上的这个问题:计算机怎么知道用户态和内核态?

陷阱

说到这里就很清晰了,用户程序无法直接执行特权指令,而它们所需的功能由操作系统封装为系统调用,并对外开放。用户程序只需要调用这些系统调用就能实现对应的功能了。

不过,how it works?当一个用户进程调用系统调用时会发生什么?

首先我们应该弄清楚一件事,这些系统调用的二进制代码放在哪里?

有一种被称为陷阱表(trap table)的东西,陷阱表告诉硬件,当发生异常、中断、或系统调用时应该运行哪些代码。陷阱表在机器启动时由操作系统(以一些特殊的特权指令)指定。这些代码被称为陷阱处理程序

有了陷阱表,硬件就知道发生系统调用时该去哪个地方运行代码了。那么我们如何触发这种调用呢?

要执行系统调用,用户程序必须执行陷阱指令(trapped instruction),同时,根据操作系统的约定,程序将一些必要的参数和调用号(指定调用哪个系统调用)放在约定好的内存空间(或寄存器)中。(这里被称为陷入操作系统

指令执行后,由于系统调用(或称陷阱处理程序)是一种过程调用,硬件会负责保存进程状态(例如保存到**内核栈(kernel stack)**中),然后将进入内核模式,跳到特定的陷阱处理程序处开始执行。

陷阱处理程序结束后,操作系统负责执行一个从陷阱返回指令(return-from-trap instruction),恢复进程状态,降低指令执行级别,进入用户模式,执行接下来用户进程的代码。

以上就是一次完整的系统调用。

上下文切换

上下文切换(context switch)

协作(cooperative)方式

操作系统可以调度进程,决定某个进程是否该在当下执行。完成这一策略的程序被称为调度程序(scheduler)

但应该注意到,当一个用户程序正在运行时,操作系统是无法运行的,试想一下,CPU 里跑的全是用户程序的指令,这显然跟操作系统半毛钱关系没有,这也就意味着操作系统没有控制权,那么 CPU 也就无法执行操作系统的调度程序,一个没有执行能力的统治阶层是没有任何意义的。

操作系统会在什么情况下运行呢?

假设一下把,通过我们刚才学到的东西,可以这样说,当机器启动时,操作系统被加载,它会做一些初始化工作,包括我们刚才说的初始化陷阱表,这时候操作系统肯定是运行着的。

然后,当用户程序陷入操作系统(例如引发异常、或发生系统调用)时,硬件触发了陷阱处理程序,这些陷阱处理程序的代码都是操作系统的一部分,所以这时候操作系统也是运行的。

但是,如果用户程序表现非常良好,没有引发异常,而且也不做一些特权操作。

举个最简单的例子,陷入死循环:

int main(){
    
    
    while(1);
    return 0;
}

按照我们刚才的假设,操作系统将永远无法拿到控制权,这就意味着操作系统将无法控制陷入死循环的、或者是其他表现良好且不发生系统调用的机器。

这被称为协作(cooperative)方式,即操作系统假定每个进程都是友好的,而且会定期让出 CPU,一般这种系统会提供一个用于让出 CPU 的系统调用,这个调用什么也不干,仅会陷入操作系统。

这种夺回控制权的方式表现并不好,如果进程拒绝进行系统调用,而且也不会出错,那么操作系统将永远无法运行,也无法做任何事情。

非协作方式

于是我们有了非协作方式,用额外的硬件时钟设备来定期发出时钟中断(timer interrupt),以陷入操作系统。令 CPU 执行特定的操作系统的代码,让操作系统拿到控制权来做它想做的事情。这里需要注意的是,当发生中断时,硬件需要保存目前的进程状态,以便在返回时恢复。

这里 CPU 因为时钟中断而执行的"特定的操作系统的代码"就是陷阱处理程序,这种非协作方式其实就相当于让一个"程序"定时调用上面说的那个用于让出 CPU 的系统调用。

保存和恢复上下文

接下来我们将完整地描述一次上下文切换。

当时钟中断发生时,硬件将保存当前进程 A 的进程状态至内核栈,随后操作系统将夺回控制权。

操作系统将做一些事情,例如,根据调度程序的策略,我们已经决定要切换到进程 B。

下面会执行一段用来切换上下文的代码段,例如称其为switch()

switch()将进程 A 的进程状态作为一个结构保存到一个列表中进行维护(以便下次切换回来时进行恢复),然后从这个列表中找到进程 B 的结构恢复到寄存器。

然后就是从陷阱返回,进程 B 将从他的内核栈恢复寄存器,然后开始执行他的代码,此时就好像刚刚陷入内核的是进程 B 一样。

这就是一次完整的上下文切换过程。

特别注意上面两次保存进程状态,第一次是为了执行陷阱处理程序而进行的,将进程状态保存到内核栈的过程。第二次是操作系统为了进行上下文切换,将进程状态作为结构保存到操作系统自己维护的列表中的过程。第二次操作直接改变了下一步执行的进程在实际内存中的位置。

switch 例程

# void swtch(struct context **old, struct context *new);
#
# Save current register context in old
# and then load register context from new.
.globl swtch
swtch:
# Save old registers
movl 4(%esp), %eax # put old ptr into eax
popl 0(%eax) # save the old IP
movl %esp, 4(%eax) # and stack
movl %ebx, 8(%eax) # and other registers
movl %ecx, 12(%eax)
movl %edx, 16(%eax)
movl %esi, 20(%eax)
movl %edi, 24(%eax)
movl %ebp, 28(%eax)

# Load new registers
movl 4(%esp), %eax # put new ptr into eax
movl 28(%eax), %ebp # restore other registers
movl 24(%eax), %edi
movl 20(%eax), %esi
movl 16(%eax), %edx
movl 12(%eax), %ecx
movl 8(%eax), %ebx
movl 4(%eax), %esp # stack is switched here
pushl 0(%eax) # return addr put in place
ret # finally return into new ctxt

猜你喜欢

转载自blog.csdn.net/qq_16181837/article/details/112295679