1. Home
  2. Embedded Linux
  3. is User/Kernel Mode Still relevant?

is User/Kernel Mode Still relevant?

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

Reply to
Tony
Loading thread data ...

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

--

formatting link
formatting link

Reply to
ellis

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.

Reply to
Geronimo W. Christ Esq

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.