CPU Switches from User mode to Kernel Mode : What exactly does it do? How does it makes this transition?

Question

CPU Switches from User mode to Kernel Mode : What exactly does it do? How does it makes this transition?

EDIT:

Even if it is architecture dependent please provide me with an answer. The architecture is up to you. Tell me for the architecture you know about.

I want to get an idea about what all things will be involved in it.

Answer 1

Note: this is mostly relevant to x86 architecture. Here's a somewhat simplified explanation.

The transition is usually caused by one of the following:

• Fault (e.g. a page fault or some other exception caused by executing an instruction)
• Interrupt (e.g. a keyboard interrupt or I/O finishing)
• Trap (e.g. a system call)

What normally happens is that system checks the Interrupt Descriptor Table (IDT). Each exception (interrupt, fault, etc.) has a number associated with it which is used to index into this table.

From this table the CPU can determine the interrupt handler to run.

As part of the transition the following changes (generally) take effect:

• Switch to Kernel stack
• EFLAGS are saved
• Code segment selector and EIP are saved.
• stack segment selector and stack pointer are saved
• Start executing the interrupt handler
• The general purpose registers are saved (handler's job)
• Segment selectors are changed to Kernel ones (handler's job)

You're now in kernel mode.

Hope that helps :)

Answer 2

That's system dependent, but the usual mechanism is some userland operation causes a software interrupt. That interrupt makes the processor switch modes and jump into kernel code, which then checks what the program was trying to do (system call?) and then does the requested action and jumps back to the user mode code. Other mechanisms besides a software interrupt might cause the transition as well; for instance in a preemptive multitasking system, a timer interrupt might trigger the scheduler to run.

Answer 3

My understanding is that any program whose segment registers have the two LSBs zero will be running in Kernel mode while any program whose segment registers have the two LSBs = 1 will be running in User Mode. In fact, the two LSBs of the segment rgeisters define the Priviledge Level (0 highest to 3 lowest)

So, to make a prgram run in Kernel mode you have to set up the segment registers to be 0010 hex (I believe). I'm not sure how you can place a program in that memory space without overwriting something else - in other words, how does the linker ensure that? Also, if you want to call the Kernel mode code from User mode code, you have to figure out how to pass parameters - they are not using the same memory soace, so can't pass data by memory reference. I guess you have to pass it in registers.

If anynody can fill in the gaps in the above, I would be very grateful.

Answer 4

In Windows, when you make a systemcall, the library routines call a kernel entrypoint residing in the operating system address space. It in turn takes the CPU into supervisor mode by executing an instruction specific for this purpose, such as sysenter. What it does is essentially setting a bit in the flags register. This enables the OS to use privileged instructions.

Answer 5

i want to give the ans based on pure logic -

-> at any time we can categorize the processes running in the main memory in 2 categories - priviledged(p) & non-priviledged(np),

-> egs for p are - OS, supervisor(in modern systems)

-> p itself is responsible for running np - it takes user processes(np) as input, and runs them by giving them the control...

-> by turing's halting problem proof, there's no general way to know when any process will do what ( ' no t.m. can decide whether a given t.m. will ever even print a given symbol in general ' ) , THUS , p (any OS) can NEVER KNOW when a certain np will try to execute a privilegdes instruction for sure..

-> HENCE, THERE HAS TO BE A HARDWIRED MECHANISM so that whenever an instruction turns out to be priviledged on decoding, the control is returned to a particular process at a particular memory location, which atleast the system believes to be trusted.

[ When i say hardwire, i mean in the microarchitecture level, i.e. no ISA shall give any explicit instruction to make such transition(duh!) , suppose if there is one, then that instruction itself must be priviledged and the system must provide an even higher level hardwired way to shift the control to p, OR any np would simply use that instruction to make transition to priviledged mode. ]

So atleast at the very core the transition must be hardwired, now although formally we can still categorize the transition based on 2 scenarios -

-> the transition is done malliciously -

• the above case is the reason people say - " without proper hardware (hardwired) support, an OS is as good as nothing ", basically implying the OS is highly vulnerable...

-> the transition is done to reduce labor (get help from the OS) -

• here the OS developers provide implementation details to language devs. as what shall be the name of the functions they can provide, what they do, what arguments they take, what preliminaries the np must do before they implement the architecture specific procedure to change cpu mode (cpu is hardwired to do the rest on its own) and so on .

• On calling these functions ( called system calls ) the compiler uses the implementation details to conform to the pre-requirements the OS requires to do the specific job, then the np making the system call performs the architecture specific way of the changing the mode - usually an instruction listed in ISA of that architecture/system, the system/cpu shifts the control to OS, the OS checks for the details it asked to be there if an np wants it to do anything, if no valid details found OS returns with error message, if found , OS does the job, on completing the job the OS returns the control to the np ....