is User/Kernel Mode Still relevant? - Embedded

This is a discussion on is User/Kernel Mode Still relevant? - Embedded ; 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 ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: is User/Kernel Mode Still relevant?

  1. 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


  2. Re: is User/Kernel Mode Still relevant?

    In article <1141260680.819210.289240@p10g2000cwp.googlegroups. com>,
    Tony wrote:

    >1- Can the user through a CPU instruction change directly the CPU mode
    >bit and the PWS content?


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

    --
    http://www.spinics.net/lists/kernel/
    http://www.spinics.net/lists/newbies/

  3. Re: is User/Kernel Mode Still relevant?

    Tony wrote:
    > 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


    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.

    > 2- i can't see why the user mode kernel mode concept is still nowadays
    > maintained.


    For security and reliability. Quite simple really.

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


    That's right.

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


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

    > there is enough hardware support to ensure that no
    > process can access unauthorised memory region of an other (user/kernel)
    > process.


    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.

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


    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 Thread