Protected mode
From Wikipedia, the free encyclopedia
Protected mode is an operational mode of x86-compatible CPUs of the 80286 series or later.
Contents |
[edit] Features
Protected mode has a number of new features designed to enhance multitasking and system stability, such as memory protection, and hardware support for virtual memory as well as task switching. It is sometimes abbreviated p-mode and also called Protected Virtual Address Mode in the Intel iAPX 286 Programmer's Reference Manual (iAPX 286 is just another name for the Intel 80286). In the 80386 and later 32-bit processors, a paging system was added and is part of protected mode.
Most modern x86 operating systems run in protected mode, including Linux, FreeBSD, OpenBSD, NetBSD and Microsoft Windows 3.0 (which also ran in real mode for compatibility with Windows 2.x applications) and later.
The other main operational mode of 286 and later CPUs is real mode, a backwards compatibility mode that disables these features, designed to allow old software to run on newer chips. As a design specification, all x86 CPUs, except the obscure embedded Intel 80376, start in real mode at boot time to ensure backwards compatibility with legacy operating systems. They must be switched into protected mode by a program before any protected mode features are available. In modern computers, this switch is usually one of the very first tasks performed by the operating system at boot time.
While software-mediated multitasking is certainly possible on systems running in real mode, the memory protection features of protected mode prevent an erroneous program from damaging the memory "owned" by another task or by the operating system kernel. Protected mode also has hardware support for interrupting a running program and shifting execution context to another, enabling pre-emptive multitasking.
[edit] Privilege levels
In protected mode, there are four privilege levels or rings, numbered from 0 to 3. Kernel code that needs to use privileged instructions runs in ring 0, and user applications normally run in ring 3.
The operating system may assign rings 1 and 2 to system services that applications can call, like network protocols or window management. Doing so lets the services directly access the data of the application, while protecting the services from the application and the kernel from the services. However, it requires the operating system to specify memory protection at the segment level (because page-level protection on the 80386 cannot distinguish between rings 0, 1, and 2) and can be difficult if the operating system needs to be portable to processors that support only two rings. An operating system can instead achieve equivalent or stronger protection by running the services in ring 3 but in a different address space. This however costs a more complex context switch at the time of the call: unless the service is given a separate Task State Segment, the processor must first switch to Ring 0 to change the address space, and then back to Ring 3 to execute the service.
The processor checks privilege levels in the following situations. If the code being run is not privileged enough, the result is usually an exception that the operating system can handle; but there are also instructions that make the same checks without raising exceptions.
- Privileged instruction. Some instructions can only be executed in ring 0: for example LGDT (load global descriptor table), which can redefine segments arbitrarily and thereby defeat the protection mechanism. POPF (pop flags from the stack) is always allowed but can change the IOPL field only in ring 0.
- Input/output. The privilege level required for I/O instructions and modifying the interrupt flag is defined via the IOPL field of EFLAGS. Even if the current privilege level does not suffice, I/O to specific ports may still be allowed via the I/O permission bit map in the task state segment (not supported by the 80286).
- Loading a segment register, and far jumps and calls. Each segment has a descriptor that defines the descriptor privilege level (DPL) required for using that segment. The selector value loaded into a segment register also encodes a requestor's privilege level (RPL), which is intended to be set with the ARPL instruction, to mark selectors received from less privileged code. The processor makes different checks for data accesses, stack switching, direct control transfers, and indirect control transfers via a gate.
- Returning to less-privileged code. The processor clears all segment registers that contain selectors that code in the new privilege level would not itself have been able to load there.
- Paging (not supported by the 80286). A bit in each page table entry controls whether the page can be used only in rings 0, 1, and 2 (supervisor mode), or also in ring 3 (user mode).
The RPL in the CS (code segment) register is always the current privilege level. Reading this register cannot be trapped, which complicates native virtualization of operating systems, as they normally expect to have ring 0 for themselves. See x86 virtualization.
[edit] 386 extensions to protected mode
These included:
- paging
- 32-bit segment offsets (this and paging made it possible to make a 32-bit flat address space with the 80386, used in modern operating systems)
- 32-bit physical address space (this extension is not present on the 80386 processors that have an 80286 bus, for example the 80386SX)
- ability to switch back to real mode
- virtual 8086 mode
- I/O permission bitmaps
Some of them used what was documented (in the Intel iAPX 286 Programmer's Reference Manual) as reserved bits on the 286.
[edit] Real mode application compatibility
The Intel iAPX 286 Programmer's Reference Manual states the protected mode is just an overlay over the 80186 instruction set, and indeed the 80286 protected mode, for application programmers, didn't add much beyond having access to up to 16 MB of physical memory and 1 GB of virtual memory (512 MB global, 512 MB local) and was binary compatible with real-mode code, so in theory, 8086 and 80186 application code could run in protected mode (albeit, slower, because loading segment registers is slower) if it followed these rules:
- no segment arithmetic
- no use of privileged instructions
- no direct hardware access
- no writing to code segment (which means that self-modifying code is never allowed)
- no executing data (that, together with segmentation, provides some buffer overflow protection)
- no assumption that segments overlap
In reality, almost all DOS application programs violated these rules, for lack of replacement DOS or BIOS calls or because of the insufficient level of performance of such calls. The most common violations were segment arithmetic and direct hardware access. Also some of the BIOS interrupts use numbers that were reserved by Intel. In other words, protected mode was less compatible with DOS applications than real mode applications would be and so there was a need for virtual 8086 mode, which came with the 386. But Windows 3.x could take advantage of the binary compatibility with real mode to run well-behaved Windows 2.x applications (which ran in real mode in Windows 2.x) in protected mode.
[edit] See also
- Real mode — Unreal mode — Virtual 8086 mode — Protected mode — Long mode
- x86
- x86 assembly language
- Ring (computer security)
[edit] External links
- http://x86.ddj.com/articles/pmbasics/tspec_a1_doc.htm
- http://colorforth.sourceforge.net/jc2007/boot.asm, a public domain example of making BIOS calls from Protected Mode by switching in and out of Unreal mode
[edit] References
- The Intel Microprocessors (8086/8088, 80186/80188, 80286, 80386, 80486, Pentium, Pentium Pro Processor, Pentium II, Pentium II, Pentium III, and Pentium 4) Architecture, Programming, and Interfacing. Barry B. Brey
- Intel Corporation (1985). iAPX 286/10 High Performance Microprocessor with Memory Management and Protection (80286-10, 80286-8, 80286-6). Order number 210253-009. In Intel Corporation (1986), Microsystem Components Handbook, Volume I: Microprocessors, ISBN 1-55512-001-6, order number 230843 (both volumes).
