I am reading Operating Systems book by Galvin. Galvin explains, what are kernel & user modes, instruction privileges given for both modes & also about mode-bit. But I am interested to know how mode changes from one to another. Basically I want to solve following question :

A CPU has 2 modes, privileged and non-privileged. In order to change the mode from previledged to non-previledged

a) A hardware interrupt is needed

b) A software interrupt is needed.

c) A privileged instruction is needed.

d) A non-privileged instruction is need.

From what I understand,

from user mode to kernel mode - Hardware Interrupt is needed [like in Disk I/O]. Now, in case user program tires to access an memory which is beyond its permissible range, a trap occurs, which is basically a software interrupt which will be handled by OS. Now, in user mode we cannot execute any privileged instructions. So, a non-privileged instruction such as I/O request can change user to kernel mode. So I think, to change

from non-privileged(user) to privileged(kernel) - H/W Interrupt, S/W Interrupt & non-Privileged instruction will do.

Now coming to, kernel to user mode. The OS can change kernel to user mode. So, it will simply run a privileged instruction to change from kernel to user mode. It does not need to generate either H/w or S/w interrupt. So I conclude, to change

from previledged to non-previledged - a privileged instruction will do.

Am I right ?

Also when executing in kernel mode, all interrupts will be disabled right ? So answer cannot be (a) or (b). Also, since OS is basically a software, it cannot generate H/W interrupts.

Also, since OS itself handles interrupts, it does not make sense to me why has to generate a interrupt (& service it) to change from kernel to user mode.

Please let me know if I am wrong anywhere. Any help regarding this is appreciated.


2 Answers 2


Usermode to kernelmode: Wrong! ;-) Yes, interrupts are processed in kernel mode, and originally the way to enter kernel mode was by an interrupt forced somehow by software. On the DEC 2020 there was a set of UIOs (Unimplemented Instruction Opcodes), calling any of those caused a trap to the operating system. They included floating point instructions (if not in hardware) and other exotic instructions, but also the means to do operating system calls. The i?86 family has the int (interrupt) instruction, traditionally used as you say. Newer members of the family have SYSTENT to do supervisor calls more efficiently. The means of going to supervisor mode can't be privileged, but must somehow be tightly controlled by the kernel (where you enter the kernel, what arguments you pass, ...).

Kernelmode to usermode: No need for the "drop privileges" operation to be privileged. If you don't have privileges, dropping them is a no-op. But the exact mechanism is architecture dependent in extreme.

Interrupts disabled in kernel: Interrupts indicate some condition that has to be handled as soon as possible (for example, if the data arrived over the net isn't saved from the card before the next arrives, it will get overwritten). Thus interrupts are very rarely disabled. In original Unix systems (and contemporaries), there was one CPU, and the simplest way to get a critical region ("nobody mess with my data while I modify it") was just to disable interrupts. Pains were taken to keep the "interrupt disabled" stretches as short as possible because of the above. On current multi-CPU machines, disabling interrupts on one CPU does nothing much in this direction; disabling interrupts globally is extremeñy costly in inter-CPU coordination, so it is not done (or extremely rarely).

  • $\begingroup$ "No need for the "drop privileges" operation to be privileged". So you mean to say, to change from Kernel to User mode, a non-privileged instruction will do. If it is a non-privileged instruction, then even a user can execute it & change from kernel to user mode ? Or did I interpret it wrong ? $\endgroup$
    – avi
    Apr 11, 2013 at 15:04
  • $\begingroup$ Yes, a "normal user" just can't get into kernel mode. Besides, dropping privileges can't do any harm, so it doesn't need to be privileged (by itself). If doing this on some machine means for example frobbing privileged registers, it will be privileged there. But it doesn't have to be privileged. $\endgroup$
    – vonbrand
    Apr 11, 2013 at 15:09
  • $\begingroup$ I am not getting it right. Your previous comment & answer contradicting itself. In comment you said, 'a "normal user" just can't get into kernel mode', but in answer, you mentioned ' "No need for the "drop privileges" operation to be privileged"'. What I am missing ? :S To simply say, in order to change Kernel to User mode, mode bit has to be changed. Which cannot be done in user mode right ? Thus it cannot be non-privileged instruction. $\endgroup$
    – avi
    Apr 11, 2013 at 15:25
  • $\begingroup$ Damn, I also didn't understood why user mode to kernel mode wrong ? In your explanation, in first few lines you mentioned user to kernel mode can be done via INT instructions & lastly you mentioned : 'The means of going to supervisor mode can't be privileged'. Isn't this all I mentioned ? H/W interrupt (which is obvious, eg. I/O requests), S/W interrupt (INT instruction) & non-privileged instruction. $\endgroup$
    – avi
    Apr 11, 2013 at 15:25
  • 1
    $\begingroup$ btw when I say 'user', I mean some program in 'user mode'. $\endgroup$
    – avi
    Apr 11, 2013 at 15:58

From kernel(privileged) to user(unprivileged) mode , we use RtI(return from interrupt) , which is a privileged instruction (https://www-01.ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.alangref/idalangref_rfi_retfinter_instrs.htm). so , according to me it should be option C.

  • 3
    $\begingroup$ What instruction is used is completely architecture-dependent. $\endgroup$ Jan 30, 2016 at 17:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.