Processor Privilege: Difference between revisions
Yuron [PHRhYmxlIGNsYXNzPSJ0d3BvcHVwIj48dHI+PHRkIGNsYXNzPSJ0d3BvcHVwLWVudHJ5dGl0bGUiPkdyb3Vwczo8L3RkPjx0ZD51c2VyPGJyIC8+YnVyZWF1Y3JhdDxiciAvPmludGVyZmFjZS1hZG1pbjxiciAvPnN5c29wPGJyIC8+PC90ZD48L3RyPjwvdGFibGU+] (talk | contribs) m (1 revision imported) |
pc>Yuron No edit summary |
||
Line 4: | Line 4: | ||
==== Privilege Levels ==== | ==== Privilege Levels ==== | ||
To facilitate [[Memory_Protection|protection]] in an operating system a | To facilitate [[Memory_Protection|protection]] in an operating system a processor may support different <strong>privilege levels</strong>. For example, a simple, two-level model will have “<strong>user</strong>” and “<strong>supervisor</strong>” modes. | ||
processor may support different <strong>privilege levels</strong>. For example, a | |||
simple, two-level model will have “<strong>user</strong>” and | |||
“<strong>supervisor</strong>” modes. | |||
*In supervisor mode the processor can do ‘anything’. | *In supervisor mode the processor can do ‘anything’. | ||
Line 16: | Line 13: | ||
Example: There will be [[Peripheral devices|I/O devices]] which interact with the outside world; these need careful handling and should not be used <em>directly</em> by applications. A reference to such a device can be detected and only allowed if the processor is currently in supervisor mode. Attempts to get at these devices by users may result in a ‘privilege violation’, preventing the action and, maybe, stopping that process although the overall computer operation can continue. | Example: There will be [[Peripheral devices|I/O devices]] which interact with the outside world; these need careful handling and should not be used <em>directly</em> by applications. A reference to such a device can be detected and only allowed if the processor is currently in supervisor mode. Attempts to get at these devices by users may result in a ‘privilege violation’, preventing the action and, maybe, stopping that process although the overall computer operation can continue. | ||
</blockquote> | </blockquote> | ||
Because privilege is monitored in hardware it does not normally | Because privilege is monitored in hardware it does not normally impinge on application execution. There is no performance penalty unless/until the user needs an OS service or misbehaves in some way. | ||
impinge on application execution. There is no performance penalty | |||
unless/until the user needs an OS service or misbehaves in some way. | |||
The privilege <em>required</em> for a given action may be specified in a | The privilege <em>required</em> for a given action may be specified in a number of ways. | ||
number of ways. | |||
*Access to memory may have programmable privilege which is set by (e.g.) entries in [[Memory Management Unit (MMU)|page tables]] in a [[Virtual_Memory|virtual memory]] system. | *Access to memory may have programmable privilege which is set by (e.g.) entries in [[Memory Management Unit (MMU)|page tables]] in a [[Virtual_Memory|virtual memory]] system. | ||
Line 29: | Line 23: | ||
*Changing the privilege level itself is restricted so it cannot be <em>increased</em> (except in specific, well-controlled ways). Thus a user cannot promote himself. | *Changing the privilege level itself is restricted so it cannot be <em>increased</em> (except in specific, well-controlled ways). Thus a user cannot promote himself. | ||
Switching into supervisor mode is only possible under certain, | Switching into supervisor mode is only possible under certain, controlled circumstances ([[exceptions]]) where it can be | ||
controlled circumstances ([[exceptions]]) where it can be | guaranteed that <strong>trusted</strong> code is run. These operating system entry points include: | ||
guaranteed that <strong>trusted</strong> code is run. These operating system entry | |||
points include: | |||
* '''[[Reset]]''' | * '''[[Reset]]''' | ||
Line 40: | Line 32: | ||
* '''[[Emulator Trap]]''' | * '''[[Emulator Trap]]''' | ||
Getting out of supervisor mode is (in principle) easy although in | Getting out of supervisor mode is (in principle) easy although in practice this is still ‘trusted code’. | ||
practice this is still ‘trusted code’. | |||
Used correctly, the privilege level can allow applications to run | Used correctly, the privilege level can allow applications to run freely – as long as they behave – but stop them from affecting other processes or crashing the system. This is a [[security]] measure, protecting against both crashes and malicious hacking. | ||
freely – as long as they behave – but stop them from affecting other | |||
processes or crashing the system. This is a [[security]] | |||
measure, protecting against both crashes and malicious hacking. | |||
===== Privilege switching ===== | ===== Privilege switching ===== | ||
A point to note is that (at the processor level) the switch both in | A point to note is that (at the processor level) the switch both in and out of the O.S. has to be [[Atomicity|atomic]]: i.e. a single instruction or similar operation. This sometimes requires the use of specialist operations such as “return from interrupt”; a modern compiler might sort this out for you automatically. | ||
and out of the O.S. has to be [[Atomicity|atomic]]: i.e. a single | |||
instruction or similar operation. This sometimes requires the use of | |||
specialist operations such as “return from interrupt”; a | |||
modern compiler might sort this out for you automatically. | |||
Take the case of <em>leaving</em> the O.S. | Take the case of <em>leaving</em> the O.S. | ||
Line 60: | Line 44: | ||
*If the code first switched out of privileged mode the next instruction fetch (in user mode, from O.S. space) would violate the privilege level and cause another exception. | *If the code first switched out of privileged mode the next instruction fetch (in user mode, from O.S. space) would violate the privilege level and cause another exception. | ||
Switches therefore have to be, effectively, simultaneous. Processors | Switches therefore have to be, effectively, simultaneous. Processors have to support this. | ||
have to support this. | |||
---- | ---- | ||
=== Other privilege modes === | === Other privilege modes === | ||
Separating operation into <em>user</em> and <em>supervisor</em> modes provides most | Separating operation into <em>user</em> and <em>supervisor</em> modes provides most of the protection needed under ordinary circumstances. However it is sometimes extended further. For example, some ARM processors contain a “[https://www.arm.com/products/security-on-arm/trustzone TrustZone<sup>®</sup>]” mode bit, which allows trusted access to certain resources by <em>some</em> user-mode applications. | ||
of the protection needed under ordinary circumstances. However it is | |||
sometimes extended further. For example, some ARM processors contain | |||
a “[https://www.arm.com/products/security-on-arm/trustzone TrustZone<sup>®</sup>]” mode bit, which allows trusted access to certain resources by <em>some</em> user-mode applications. | |||
More generally, as computers (and users) grow more sophisticated there | More generally, as computers (and users) grow more sophisticated there is a demand for virtualisation of the operating system itself, enabling (say) the same machine to be running Linux and Windows simultaneously. The difficulty is that each operating system believes it has sole control of the machine’s hardware. This can be detected and trapped by the addition of a further | ||
is a demand for virtualisation of the operating system itself, | “[[hypervisor]]” mode with its accompanying software. | ||
enabling (say) the same machine to be running Linux and Windows | |||
simultaneously. The difficulty is that each operating system believes | |||
it has sole control of the machine’s hardware. This can be detected | |||
and trapped by the addition of a further | |||
“[[hypervisor]]” mode with its accompanying | |||
software. | |||
---- | ---- | ||
The privilege level of the processor is similar <em>in principle</em> to the | The privilege level of the processor is similar <em>in principle</em> to the concept of a ‘[[superuser]]’ (a.k.a. “root” or | ||
concept of a ‘[[superuser]]’ (a.k.a. “root” or | “admin”) in system management. However it is <em>not</em> the same thing; it is an operation mode maintained by the processor and may tested for every instruction executed. | ||
“admin”) in system management. However it is <em>not</em> the | |||
same thing; it is an operation mode maintained by the processor and | |||
may tested for every instruction executed. | |||
---- | ---- | ||
{{BookChapter|1.4.2|24-26}} | |||
{{PageGraph}} | {{PageGraph}} | ||
{{Category|Concepts}} | {{Category|Concepts}} | ||
{{Category|Major concepts}} | {{Category|Major concepts}} | ||
{{Category|Security}} | {{Category|Security}} |
Revision as of 10:16, 3 August 2019
On path: OS Topics | 1: Concepts • 2: Cache • 3: Context • 4: Processor Privilege • 5: Process Scheduling • 6: Exceptions • 7: Interrupts • 8: Direct Memory Access (DMA) • 9: Virtualisation • 10: Hypervisor |
---|
Depends on | Security |
---|
Privilege Levels
To facilitate protection in an operating system a processor may support different privilege levels. For example, a simple, two-level model will have “user” and “supervisor” modes.
- In supervisor mode the processor can do ‘anything’.
- In user mode, some actions are forbidden – including altering the mode!
The mode is visible to the hardware which can use this information to decide whether to allow an action to take place. It is arguably this distinction of privilege which determines if something is part of the OS kernel.
Example: There will be I/O devices which interact with the outside world; these need careful handling and should not be used directly by applications. A reference to such a device can be detected and only allowed if the processor is currently in supervisor mode. Attempts to get at these devices by users may result in a ‘privilege violation’, preventing the action and, maybe, stopping that process although the overall computer operation can continue.
Because privilege is monitored in hardware it does not normally impinge on application execution. There is no performance penalty unless/until the user needs an OS service or misbehaves in some way.
The privilege required for a given action may be specified in a number of ways.
- Access to memory may have programmable privilege which is set by (e.g.) entries in page tables in a virtual memory system.
- The memory containing the page tables would normally also be protected.
- Access to some devices may require privilege and be set when the machine (usually a single chip, these days) was built. The Memory Management Unit (MMU) would be one such example.
- Altering the interrupt status (to allow more/fewer interrupts) is a privileged operation. Interrupt service routines are part of the OS code and users should not be able to turn them on and off.
- Changing the privilege level itself is restricted so it cannot be increased (except in specific, well-controlled ways). Thus a user cannot promote himself.
Switching into supervisor mode is only possible under certain, controlled circumstances (exceptions) where it can be guaranteed that trusted code is run. These operating system entry points include:
Getting out of supervisor mode is (in principle) easy although in practice this is still ‘trusted code’.
Used correctly, the privilege level can allow applications to run freely – as long as they behave – but stop them from affecting other processes or crashing the system. This is a security measure, protecting against both crashes and malicious hacking.
Privilege switching
A point to note is that (at the processor level) the switch both in and out of the O.S. has to be atomic: i.e. a single instruction or similar operation. This sometimes requires the use of specialist operations such as “return from interrupt”; a modern compiler might sort this out for you automatically.
Take the case of leaving the O.S.
- If the code first branched back to the user then this assumes the user code would relinquish the privilege: a dangerous security hole.
- If the code first switched out of privileged mode the next instruction fetch (in user mode, from O.S. space) would violate the privilege level and cause another exception.
Switches therefore have to be, effectively, simultaneous. Processors have to support this.
Other privilege modes
Separating operation into user and supervisor modes provides most of the protection needed under ordinary circumstances. However it is sometimes extended further. For example, some ARM processors contain a “TrustZone®” mode bit, which allows trusted access to certain resources by some user-mode applications.
More generally, as computers (and users) grow more sophisticated there is a demand for virtualisation of the operating system itself, enabling (say) the same machine to be running Linux and Windows simultaneously. The difficulty is that each operating system believes it has sole control of the machine’s hardware. This can be detected and trapped by the addition of a further “hypervisor” mode with its accompanying software.
The privilege level of the processor is similar in principle to the concept of a ‘superuser’ (a.k.a. “root” or “admin”) in system management. However it is not the same thing; it is an operation mode maintained by the processor and may tested for every instruction executed.
Also refer to: | Operating System Concepts, 10th Edition: Chapter 1.4.2, pages 24-26 |
---|