is User/Kernel Mode Still relevant?

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View

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???


Re: is User/Kernel Mode Still relevant?

Quoted text here. Click to load it

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

-- / /

Re: is User/Kernel Mode Still relevant?
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

For security and reliability. Quite simple really.

Quoted text here. Click to load it

That's right.

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

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Site Timeline