Device drivers and other trusted modules need to be able to protect themselves against interrupts, have access to privileged instructions, etc., for some part of their operation. The code that requires this access is often a tiny proportion of the total module; however, most operating systems would require that the whole module run in kernel mode, whether linked statically or dynamically loaded. Furthermore, it becomes a property of the code that it runs in kernel mode, rather than the data the code is manipulating.
... <unpriviledged code>
begin_KPS(); /* enter privileged section */
TRY
... <privileged code>
FINALLY
end_KPS(); /* leave privileged section */
END;
... <unpriviledged code>
Figure 5: Coding a Kernel-Privileged Section
Nemesis offers the concept of the Kernel-Privileged Section to meet the requirement for a dynamic and extensible means to provide access to kernel mode. Privileged domains may define sections of their code which need to be executed in kernel mode. In a block-structured language this would naturally be a basic block enclosed with some form of TRY FINALLY construct allowing privileged code to raise exceptions but forcing the thread to leave kernel mode before any handler outside the privileged section is invoked (see Figure 5). The implementation of the Kernel-Privileged Section (i.e. the begin_KPS and end_KPS) is highly processor dependent -- on 68k, MIPS and ARM processors it leads to various traps implemented in a non-procedural manner, while the aim on the Alpha is to implement a PAL instruction to achieve the desired effect.
In many ways the Kernel-Privileged Section idea is akin to using locked critical sections for currency control, whereas most other operating systems have a model of kernel mode access more akin to monitored procedures.