[ostep] 03 virtualized CPU - restricted direct execution mechanism

Restricted direct execution

We have learned the abstract concept of process , Now let's get to the specific mechanism , I said before , Mechanism is the implementation details of a function , The strategy is similar to the scheduling of mechanism .

The first mechanism to learn is called Restricted direct execution （Limited Direct Execution）.

As an excellent operating system , Instructions that can lead to danger should be carefully provided （ For example, for hard disk IO operation , call Privileged orders ）, These operations are encapsulated by the operating system as system call （system call）.

But there is a problem , The system call is also a long sequence of instructions after all , It seems to be no different from the user's program . After all CPU When executing an instruction, you will not consider whose instruction it is . Besides, this " who " It's just our abstraction , process （ Or program ） Lifeless , There is no process at the hardware level , They are just instruction data to be executed in memory .

So how should the operating system protect privileged instructions ？ What happens when a user program invokes a privileged instruction ？

Kernel mode and user mode

modern CPU Have multiple instruction execution levels , That is, instructions at specific levels can be executed at different levels , These levels can be divided into two modes ： Kernel mode （kernel mode） and User mode （user mode）.

These execution levels are achieved by hardware ,CPU The value in a specific register is checked to determine the current execution level , These logic are designed in hardware .

When the machine starts , The bootstrap will load the operating system , At this time, the operating system is running in kernel mode , From now on , At what execution level does any user program run , It's entirely up to the operating system to decide .

Like the ruling class of human society , If they don't let people use their privileges , People will never have a chance to become the ruling class . In other words , Any program running in kernel mode has the opportunity to turn itself into a ruling class . This reminds me of the veto power of the five permanent members of the United Nations , Only with the consent of the P5 itself , Only other countries can abolish the one vote veto of the five permanent members , Otherwise, other countries will have no chance , Because the five permanent members can directly veto by one vote " Abolish one vote veto " Proposal for .

That's what's called " Restricted direct execution " Of " be limited to " The meaning of .

Answer the second question , What happens when a user program invokes a privileged instruction ？

Generally speaking , When an instruction of a process does not match the current execution level ,CPU Will be abnormal , At this time, the operating system may choose to terminate the process .

The understanding here can refer to the problem of Zhihu ： How does the computer know user mode and kernel mode ？

trap

That's clear , User programs cannot directly execute privileged instructions , The functions they need are encapsulated by the operating system as system calls , And open to the outside world . The user program only needs to call these system calls to realize the corresponding functions .

however ,how it works？ What happens when a user process invokes a system call ？

First of all, we should make one thing clear , Where are the binary codes of these system calls ？

There is one called Trap table （trap table） Things that are , The trap table tells the hardware , When something goes wrong 、 interrupt 、 Or what code should be run when the system is called . The trap table is controlled by the operating system when the machine is started （ With some special privileged instructions ） Appoint . These codes are called Trap handler .

With the trap table , The hardware knows where to run the code when a system call occurs . So how do we trigger this call ？

To perform a system call , The user program must execute Trap command （trapped instruction）, meanwhile , According to the agreement of the operating system , The program adds some necessary parameters and call numbers （ Specify which system call to call ） Put it in the agreed memory space （ Or register ） in .（ It's called Trapped in the operating system ）

After the command is executed , Due to system call （ Or trap handler ） Is a procedure call , The hardware will be responsible for saving the process status （ For example, save to ** Kernel stack （kernel stack）** in ）, Then it will enter kernel mode , Jump to a specific trap handler and start execution .

After the trap handler ends , The operating system is responsible for executing a Return instructions from traps （return-from-trap instruction）, Restore process state , Lower the instruction execution level , Enter user mode , Execute the code of the next user process .

The above is a complete system call .

Context switch

Context switch (context switch)

Collaboration （cooperative） The way

The operating system can schedule processes , Decide whether a process should be executed now . The process of accomplishing this strategy is called The scheduler （scheduler）.

But it should be noted that , When a user program is running , The operating system cannot run , Just imagine ,CPU It's full of user program instructions , This obviously has nothing to do with the operating system for half a cent , This means that the operating system has no control , that CPU It is impossible to execute the scheduler of the operating system , A ruling class without executive ability is meaningless .

Under what conditions will the operating system run ？

Suppose , Through what we just learned , It can be said that , When the machine starts , The operating system is loaded , It does some initialization , Including the initialization trap table we just mentioned , At this time, the operating system must be running .

then , When the user program gets stuck in the operating system （ For example, an exception is thrown 、 Or system call occurs ） when , The hardware triggered the trap handler , The code of these trap handlers is part of the operating system , So at this time, the operating system is also running .

however , If the user program performs very well , No exception was thrown , And do not do some privileged operations .

Let's take the simplest example , Fall into a dead cycle ：

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

According to our assumption just now , The operating system will never get control , This means that the operating system will not be able to control the 、 Or other machines that perform well and do not make system calls .

This is known as Collaboration （cooperative） The way , That is, the operating system assumes that every process is friendly , And will give up regularly CPU, Generally, this system will provide one for giving up CPU System call , This call does nothing , Will only fall into the operating system .

This way of regaining control is not good , If the process refuses to make a system call , And it won't go wrong , Then the operating system will never run , Can't do anything .

Non collaborative way

So we have Non collaborative way , With extra hardware Clock devices To be sent regularly Clock interrupt （timer interrupt）, To get into the operating system . Make CPU Execute the code of a specific operating system , Let the operating system take control and do what it wants . What needs to be noted here is , When there is an interruption , The hardware needs to save the current process state , In order to recover on return .

here CPU Executed due to clock interruption " The code of a specific operating system " Is the trap handler , This non collaborative approach is actually equivalent to letting a " Program " Call the one mentioned above regularly to give up CPU System call .

Save and restore context

Next, we will fully describe a context switch .

When a clock interrupt occurs , The hardware will save the current process A Process state to kernel stack , Then the operating system will regain control .

The operating system will do something , for example , According to the scheduler's strategy , We have decided to switch to the process B.

A code snippet for switching context will be executed below , For example, call it switch().

switch() Meeting Process A The process state of is saved to a list as a structure for maintenance （ So that you can recover the next time you switch back ）, Then find the process from this list B The structure of is restored to the register .

Then return from the trap , process B Will recover registers from his kernel stack , Then start executing his code , At this point, it is like a process that has just fallen into the kernel B equally .

This is a complete context switching process .

Pay special attention to the process status saved in the above two times , The first is to execute the trap handler , The process of saving process state to the kernel stack . The second time is for the operating system to switch context , The process of saving the process state as a structure to the list maintained by the operating system itself . The second operation directly changes the location of the next process in the actual memory .

switch routine

# 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