Developer Forum

I was wondering if someone could explain to me the difference between
Kernel Mode and User Mode as it pertains to the ia32 architecture
modes. I was under the impression that the current standard had three
modes: protected mode, real-address mode, and system management mode.
Is there any correspondence between the different linux modes and the
ia32 modes or does linux create two segments within protected mode?
Thank you for anyone that can help.

Paul

These are really two different entities.

IA32 architecture modes apply to the processor. Usually when the pc is
booted up, it is in real-address mode. System management mode would apply
to hardware that supports a system management interface, perhaps notebooks,
or a button on the case to enter the system management mode.

As Linux starts up, it puts the processor into protected mode, to enable
other features of the ia32 architecture, such as access beyond the 1 MB
boundary, paging, and protected mode segments and descriptors.

Kernel mode and usermode are operation concepts within linux, and are not
dependent on the ia32 mode architecture. Kernel mode generally refers to
the operating system, kernel modules, device drivers, and networking
services. Usermode generally refers to processes and applications that
would be running on the system.

Hope this helps
--
Travis Hein
Keyboard not found.
Press F1 to continue...

To quote a passage from the book "Understanding the Linux Kernel" by
Daniel P. Bovet & Marco Cesati:

In particular, the hardware introduces at least two different
execution modes for the CPU: a nonprivileged mode for user programs
and a privileged mode for the kernel. Unix calls these User Mode and
Kernel Mode, respectively.

This implies that these are actually hardware switches. I noticed in
Volume 3 of the IA32 Manual that bit 17 in the EFLAGS register is used
to switch to 8086 mode or real mode. Is this text wrong or am I just
misunderstanding it? What source file is it that actually switches
modes, would that be a property of the scheduler? Thank you for any
help you can provide :)

PAUL

Yes, in Intel architecture there are 2 bit fields (DPL) for the protection
level in most of the segment descriptors.
The 'VM' flag, bit 17 of EFLAGS is for virtual 8086 mode, which denotes the
currently running task (pointed to by GDT, LDT, or IDT) is using an
addressing mode that is compatible with the 8086 address mode.
All this stuff are hardware data types and structures and modes specific to
the Intel architecture protected mode implementation.

In Linux kernel, there is a high level structure called 'task_struct'. This
and other kernel structures abstract or insulate the operation of the
kernel at the lowest level from the intel architecture implementation of
protected mode descriptors, and status flags of the eflags register.

some of the files in the linux kernel source that relate to this (for intel
architecture) are
init/main.c
kernel/sched.c
arch/i386/kernel/setup.c
arch/i386/kernel/process.c
arch/i386/kernel/ldt.c

a good place to get a handle on the 'high level' structures used by Linux to
manipulate cpu and memory resources is in:
include/linux/sched.h

The kernel mode in linux applies to kernel memory address space, where by
the memory map area (structures in include/linux/mm.h) are reserved or
allowed access only by the kernel, and modules / drivers that may be loaded
into the kernel.
User mode, is the area of memory, modeled with linux data structures, and
has permissions set such that running processes outside of the kernel may
access.

So, the workings of intel architecture protected mode vs 8086 mode
and usermode vs kernel mode are kind of seperate concepts. This is also how
Linux is able to work on other architectures that do not implement the
fruitful protected mode virtual address segmentation model of Intel
architectures.

Hope this is helpful

--
Travis Hein
Keyboard not found.
Press F1 to continue...

> Yes, in Intel architecture there are 2 bit fields (DPL) for the protection

Oh I see, so the passage I quoted, in it implications, is a bit
misleading. I took it to suggest that the kernel actually made a
switch on the hardware level from protected mode to some other mode
(interestingly enough, that mode was not explained). What you say
makes a lot of sense. As I was thinking to myself of the implications
of such a switch to 8086 compatibility (therein pointing to backwards
compatibility with an archaic architecture) it came to me at how
inefficient such an act would be given the limitations of the 8086
architecture. This is why I was confused on this matter from the
beginning.

Well I thank you for your time and most appreciate your patience with
one who is just beginning to learn the complexities of a most
fascinating piece of art and work.

Paul