is User/Kernel Mode Still relevant?

Mar 02, 2006 2 Replies
T

Heya,



I am little confused about the following issues, which i would appreciate your help.


1- Can the user through a CPU instruction change directly the CPU mode bit and the PWS content? Or does he have to call INT so the mode bit is set to 1 and RETE to reset it back to 0


2- i can't see why the user mode kernel mode concept is still nowadays maintained. i understand that with user mode, user applications have some restrictions. they can't access the computer system devices directly, while with mode bit set to kernel or supervisor mode, the whole system components can be altered. I understand that for security reasons, accessing memory and IO devices has to be done by a code (kernel code, driver code) which has been thouroughly tested and carefully and efficiently written. however, why a need to switch the CPU mode bit??? there is enough hardware support to ensure that no process can access unauthorised memory region of an other (user/kernel) process. so presumably this mode bit setting has not been maintained to protect processes from each other as dedicated hardware is there to trap the OS in case of unauthorised access but rather maintained for another reason ..... any help with example please???



Thanks



Vote
Twitter Facebook LinkedIn
E

Wouldn't that be a hell of a security issue?

--

formatting link
formatting link

Vote
Twitter Facebook LinkedIn
G

What CPU are you talking about ?

.. most CPUs have a class of instruction which may only be executed in ring 0 or kernel mode. It is impossible for user space code to crash the system unless the kernel grants it privileges to access, eg, device driver memory.

If by "mode bit" you mean kernel or supervisor mode, that bit cannot be set in user mode. The CPU enters kernel mode usually only either when an interrupt occurs, or when the user space code invokes a system call (which is really just a type of interrupt). Kernel mode is always entered via an exception handler so the kernel is always in control in this state.

For security and reliability. Quite simple really.

That's right.

So that the kernel can police unauthorized activity coming from user space.

There is no hardware support in existence that can deal with "unauthorized" memory. The hardware does not know which accesses are authorized, and which are not.

It is the kernel which does this, not the hardware. If your memory access is unauthorized, it is the kernel which will kill you and dump your core.

I think you misunderstand how the MMU works. You will find that the MMU will trap relatively frequently; generally there is much more memory in a system than there are TLB entries to map them all. It is the kernel which deals with the MMU traps and decides whether access are unauthorized or not.

Vote
Twitter Facebook LinkedIn

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required