View source for Protection ring

{{short description|Layer of protection in computer systems}}
{{redirect-several|Ring|Ring 0}}
{{Use dmy dates|date=January 2021}}
{{More footnotes needed|date=February 2015}}
[[File:Priv rings.svg|300px|thumb|right|Privilege rings for the [[x86]] available in [[protected mode]] ]]

In [[computer science]], '''hierarchical protection domains''',<ref>{{Cite conference|doi=10.1109/SP.1984.10001|title=An Augmented Capability Architecture to Support Lattice Security and Traceability of Access|conference=1984 IEEE Symposium on Security and Privacy|year=1984|last1=Karger|first1=Paul A.|last2=Herbert|first2=Andrew J.|page=2|isbn=0-8186-0532-4|s2cid=14788823}}</ref><ref>{{Cite conference|doi = 10.1109/SAINT.2001.905166|title = Design and implementation of the J-SEAL2 mobile agent kernel|book-title = Proceedings 2001 Symposium on Applications and the Internet|year = 2001|last1 = Binder|first1 = W.|pages = 35–42|isbn = 0-7695-0942-8|s2cid = 11066378}}</ref> often called '''protection rings''', are mechanisms to protect data and functionality from faults (by improving [[fault tolerance]]) and malicious behavior (by providing [[computer security]]).

Computer operating systems provide different levels of access to resources. A protection ring is one of two or more hierarchical ''levels'' or ''layers'' of [[Privilege (computing)|privilege]] within the architecture of a [[computer system]]. This is generally hardware-enforced by some [[Central processing unit|CPU]] [[Computer architecture|architecture]]s that provide different [[CPU modes]] at the hardware or [[microcode]] [[abstraction layer|level]]. Rings are arranged in a hierarchy from most privileged (most trusted, usually numbered zero) to least privileged (least trusted, usually with the highest ring number). On most operating systems, Ring 0 is the level with the most privileges and interacts most directly with the physical hardware such as certain CPU functionality (e.g. the control registers) and I/O controllers. 

Special mechanisms are provided to allow an outer ring to access an inner ring's resources in a predefined manner, as opposed to allowing arbitrary usage. Correctly gating access between rings can improve security by preventing programs from one ring or privilege level from misusing resources intended for programs in another. For example, [[spyware]] running as a user program in Ring 3 should be prevented from turning on a web camera without informing the user, since hardware access should be a Ring 1 function reserved for [[device driver]]s. Programs such as web browsers running in higher numbered rings must request access to the network, a resource restricted to a lower numbered ring.

X86S, a canceled Intel architecture published in 2024, has only ring 0 and ring 3. Ring 1 and 2 were to be removed under X86S since modern OSes never utilize them.<ref>{{Cite web |title=Envisioning a Simplified Intel Architecture for the Future |url=https://www.intel.com/content/www/us/en/developer/articles/technical/envisioning-future-simplified-architecture.html |access-date=2024-05-28 |website=Intel |language=en}}</ref><ref>{{cite book|last=Tanembaum|first=Andrew S.|title=Modern Operating Systems|edition=4th|year=2015|pages=479–480|publisher=[[Pearson PLC|Pearson]]|isbn= 978-0-13-359162-0|quote=For many years, the x86 has supported four protection modes or rings [...]. Ring 3 is the least privileged [...]. Ring 0 is the most privileged [...]. The remaining two rings are not used by any current operating system.}}</ref>

==Implementations==
Multiple rings of protection were among the most revolutionary concepts introduced by the [[Multics]] operating system, a highly secure predecessor of today's [[Unix]] family of operating systems. The [[GE 645]] mainframe computer did have some hardware access control, including the same two modes that the other GE-600 series machines had, and segment-level permissions in its [[memory management unit]] ("Appending Unit"), but that was not sufficient to provide full support for rings in hardware, so Multics supported them by trapping ring transitions in software;<ref>{{cite journal|title=A Hardware Architecture for Implementing Protection Rings|url=http://www.multicians.org/protection.html|journal=[[Communications of the ACM]]|date=March 1972|volume=15 |issue=3|access-date=27 September 2012}}</ref> its successor, the [[Honeywell 6180]], implemented them in hardware, with support for eight rings;<ref>{{cite web|title=Multics Glossary - ring|url=http://www.multicians.org/mgr.html#ring|access-date=27 September 2012}}</ref>  Protection rings in Multics were separate from CPU modes; code in all rings other than ring 0, and some ring 0 code, ran in slave mode.<ref>{{cite book|url=http://www.bitsavers.org/pdf/honeywell/large_systems/multics/haley/AG95_part2_Jun72.pdf|title=The Multics Virtual Memory, part 2|date=June 1972|pages=160–161|publisher=Honeywell Information Systems}}</ref>

However, most general-purpose systems use only two rings, even if the hardware they run on provides more [[CPU modes]] than that. For example, Windows 7 and Windows Server 2008 (and their predecessors) use only two rings, with ring 0 corresponding to [[#SUPERVISOR-MODE|kernel mode]] and ring 3 to [[user space|user mode]],<ref name="russinovich"/> because earlier versions of Windows NT ran on processors that supported only two protection levels.<ref>{{cite book|last=Russinovich|first=Mark|title=Windows Internals Part 1|edition=6th |year=2012|publisher=Microsoft Press|location=Redmond, Washington|isbn=978-0-7356-4873-9|page=17|quote=The reason Windows uses only two levels is that some hardware architectures that were supported in the past (such as [[DEC Alpha|Compaq Alpha]] and [[MIPS architecture|Silicon Graphics MIPS]]) implemented only two privilege levels.}}</ref>

Many modern CPU architectures (including the popular [[Intel]] [[x86]] architecture) include some form of ring protection, although the [[Windows NT]] operating system, like Unix, does not fully utilize this feature. [[OS/2]] does, to some extent, use three rings:<ref>{{Cite web |url=http://cyberkinetica.homeunix.net/os2tk45/ddk_pdrref/005_L1_IntroductiontoOS2Pre.html |title=Presentation Device Driver Reference for OS/2 – 5. Introduction to OS/2 Presentation Drivers |access-date=13 June 2015 |archive-url=https://web.archive.org/web/20150615030714/http://cyberkinetica.homeunix.net/os2tk45/ddk_pdrref/005_L1_IntroductiontoOS2Pre.html |archive-date=15 June 2015 |url-status=dead }}</ref> ring 0 for kernel code and device drivers, ring 2 for privileged code (user programs with I/O access permissions), and ring 3 for unprivileged code (nearly all user programs). Under [[DOS]], the kernel, drivers and applications typically run on ring 3 (however, this is exclusive to the case where protected-mode drivers or DOS extenders are used; as a real-mode OS, the system runs with effectively no protection), whereas 386 memory managers such as [[EMM386]] run at ring 0. In addition to this, [[DR-DOS]]' EMM386 3.xx can optionally run some modules (such as [[DOS Protected Mode Services|DPMS]]) on ring 1 instead. [[OpenVMS]] uses four modes called (in order of decreasing privileges) Kernel, Executive, Supervisor and User.
[[File:Most common protection rings.svg|thumb|While x86 has 4 protection rings, it is more common for architectures to only have two. Even on x86, most [[operating systems]] only use ring 0 and 3.]]
A renewed interest in this design structure came with the proliferation of the [[Xen]] [[hypervisor|VMM]] software, [[Tanenbaum–Torvalds debate|ongoing discussion]] on [[Monolithic kernel|monolithic]] vs. [[Microkernel|micro-kernels]] (particularly in [[Usenet]] newsgroups and [[Internet forum|Web forum]]s), Microsoft's ''Ring-1'' design structure as part of their [[Next-Generation Secure Computing Base|NGSCB]] initiative, and [[hypervisor]]s based on [[x86 virtualization]] such as [[Intel VT-x]] (formerly Vanderpool).

The original Multics system had eight rings, but many modern systems have fewer. The hardware remains aware of the current ring of the executing instruction [[Thread (computing)|thread]] at all times, with the help of a special machine register. In some systems, areas of [[virtual memory]] are instead assigned ring numbers in hardware.  One example is the [[Data General Eclipse MV/8000]], in which the top three bits of the [[program counter|program counter (PC)]] served as the ring register. Thus code executing with the virtual PC set to 0xE200000, for example, would automatically be in ring 7, and calling a subroutine in a different section of memory would automatically cause a ring transfer.

The hardware severely restricts the ways in which control can be passed from one ring to another, and also enforces restrictions on the types of memory access that can be performed across rings. Using x86 as an example, there is a special{{clarify|date=November 2015}} ''gate'' structure which is referenced by the ''call'' instruction that transfers control in a secure way{{clarify|date=November 2015}} towards predefined entry points in lower-level (more trusted) rings; this functions as a [[supervisor call]] in many operating systems that use the ring architecture. The hardware restrictions are designed to limit opportunities for accidental or malicious breaches of security.  In addition, the most privileged ring may be given special capabilities (such as real memory addressing that bypasses the virtual memory hardware).

[[ARM architecture|ARM]] version 7 architecture implements three privilege levels: application (PL0), operating system (PL1), and hypervisor (PL2). Unusually, level&nbsp;0 (PL0) is the least-privileged level, while level&nbsp;2 is the most-privileged level.<ref>{{cite book|url=https://developer.arm.com/documentation/ddi0406/latest|title=ARM Architecture Reference Manual ARMv7-A and ARMv7-R edition|page=B1{{hyp}}1136|publisher=[[Arm Ltd.]]}}</ref> ARM version 8 implements four exception levels: application (EL0), operating system (EL1), hypervisor (EL2), and secure monitor / firmware (EL3), for AArch64<ref name="armv8-a">{{cite book|url=https://developer.arm.com/documentation/ddi0487/latest|title=Arm Architecture Reference Manual Armv8, for A-profile architecture|publisher=[[Arm Ltd.]]}}</ref>{{rp|D1{{hyp}}2454}} and AArch32.<ref name="armv8-a" />{{rp|G1{{hyp}}6013}}

Ring protection can be combined with [[processor modes]] (master/kernel/privileged/[[#SUPERVISOR-MODE|supervisor mode]] versus slave/unprivileged/user mode) in some systems. Operating systems running on hardware supporting both may use both forms of protection or only one.

Effective use of ring architecture requires close cooperation between hardware and the operating system.{{why|date=November 2015}} Operating systems designed to work on multiple hardware platforms may make only limited use of rings if they are not present on every supported platform. Often the security model is simplified to "kernel" and "user" even if hardware provides finer granularity through rings. <ref>{{cite book|last=Tanembaum|first=Andrew S.|title=Modern Operating Systems|edition=4th|year=2015|pages=479–480|publisher=[[Pearson PLC|Pearson]]|isbn= 978-0-13-359162-0|quote=For many years, the x86 has supported four protection modes or rings [...]. Ring 3 is the least privileged [...]. Ring 0 is the most privileged [...]. The remaining two rings are not used by any current operating system.}}</ref>

==Modes==
{{see also|Real mode|Protected mode}}

==={{Anchor|SUPERVISOR-MODE}}Supervisor mode===
In computer terms, ''supervisor mode'' is a hardware-mediated flag that can be changed by code running in system-level software. System-level tasks or threads may{{efn|E.g., In IBM [[OS/360]] through [[z/OS]], some system tasks run in problem state key 0.}} have this flag set while they are running, whereas user-level applications will not. This flag determines whether it would be possible to execute machine code operations such as modifying registers for various descriptor tables, or performing operations such as disabling interrupts. The idea of having two different modes to operate in comes from "with more power comes more responsibility"{{snd}} a program in supervisor mode is trusted never to fail, since a failure may cause the whole computer system to crash.

Supervisor mode is "an execution mode on some processors which enables execution of all instructions, including privileged instructions. It may also give access to a different address space, to memory management hardware and to other peripherals. This is the mode in which the operating system usually runs."<ref>{{cite web|website=[[Free On-line Dictionary of Computing|FOLDOC]]|url=https://foldoc.org/Supervisor+Mode|title=supervisor mode|date=1995-02-15}}</ref>

In a [[monolithic kernel]], the operating system runs in supervisor mode and the applications run in user mode. Other types of [[operating system]]s, like those with an [[exokernel]] or [[microkernel]], do not necessarily share this behavior.

Some examples from the PC world:

* [[Linux kernel|Linux]], [[macOS]] and [[Microsoft Windows|Windows]] are three operating systems that use supervisor/user mode. To perform specialized functions, user mode code must perform a [[system call]] into supervisor mode or even to the kernel space where trusted code of the operating system will perform the needed task and return the execution back to the userspace. Additional code can be added into kernel space through the use of [[loadable kernel module]]s, but only by a user with the requisite permissions, as this code is not subject to the access control and safety limitations of user mode.
* [[DOS]] (for as long as no 386 memory manager such as [[EMM386]] is loaded), as well as other simple operating systems and many embedded devices run in supervisor mode permanently, meaning that drivers can be written directly as user programs.

Most processors have at least two different modes. The [[x86]]-processors have four different modes divided into four different rings. Programs that run in Ring 0 can do ''anything'' with the system, and code that runs in Ring 3 should be able to fail at any time without impact to the rest of the computer system. Ring 1 and Ring 2 are rarely used, but could be configured with different levels of access.

In most existing systems, switching from user mode to kernel mode has an associated high cost in performance. It has been measured, on the basic request <code>[[Process identifier|getpid]]</code>, to cost 1000–1500 cycles on most machines. Of these just around 100 are for the actual switch (70 from user to kernel space, and 40 back), the rest is "kernel overhead".<ref name="Liedtke95">{{cite conference |author=Jochen Liedtke |author-link=Jochen Liedtke |url=https://os.itec.kit.edu/65_1029.php |title=On µ-Kernel Construction |book-title=Proc. 15th ACM Symposium on Operating System Principles (SOSP) |date=December 1995}}</ref><ref name="Ousterhout90">{{cite conference |last=Ousterhout |first=J. K. |author-link=John Ousterhout |date=1990 |title=Why aren't operating systems getting faster as fast as hardware? |conference=Usenix Summer Conference A|location=naheim, CA |pages=247–256}}</ref> In the [[L3 microkernel]], the minimization of this overhead reduced the overall cost to around 150 cycles.<ref name="Liedtke95"/>

[[Maurice Wilkes]] wrote:<ref>{{cite journal|author=Maurice Wilkes|author-link=Maurice Wilkes|doi=10.1145/198153.198154|title=Operating systems in a changing world|journal=ACM SIGOPS Operating Systems Review|volume=28|issue=2|date=April 1994|pages=9–21|s2cid=254134|issn=0163-5980|doi-access=free}}</ref> <blockquote>... it eventually became clear that the hierarchical protection that rings provided did not closely match the requirements of the system programmer and gave little or no improvement on the simple system of having two modes only. Rings of protection lent themselves to efficient implementation in hardware, but there was little else to be said for them. [...] The attractiveness of fine-grained protection remained, even after it was seen that rings of protection did not provide the answer... This again proved a blind alley... </blockquote>

To gain performance and determinism, some systems place functions that would likely be viewed as application logic, rather than as device drivers, in kernel mode; security applications ([[access control]], [[firewall (computing)|firewalls]], etc.) and operating system monitors are cited as examples. At least one embedded database management system, [[EXtremeDB#Kernel mode deployment|''e''X''treme''DB Kernel Mode]], has been developed specifically for kernel mode deployment, to provide a local database for kernel-based application functions, and to eliminate the [[context switch]]es that would otherwise occur when kernel functions interact with a database system running in user mode.<ref>{{cite magazine |last1=Gorine |first1=Andrei |last2=Krivolapov |first2=Alexander |url=http://www.ddj.com/database/207401567 |title=Kernel Mode Databases: A DBMS Technology For High-Performance Applications |magazine=Dr. Dobb's Journal |date=May 2008}}</ref>

Functions are also sometimes moved across rings in the other direction. The Linux kernel, for instance, injects into processes a [[vDSO]] section which contains functions that would normally require a system call, i.e. a ring transition. Instead of doing a syscall these functions use static data provided by the kernel.  This avoids the need for a ring transition and so is more lightweight than a syscall. The function gettimeofday can be provided this way.

===Hypervisor mode===
Recent CPUs from Intel and AMD offer [[x86 virtualization]] instructions for a [[hypervisor]] to control Ring&nbsp;0 hardware access. Although they are mutually incompatible, both [[Intel VT-x]] (codenamed "Vanderpool") and [[X86 virtualization#AMD virtualization (AMD-V)|AMD-V]] (codenamed "Pacifica") allow a guest operating system to run Ring&nbsp;0 operations natively without affecting other guests or the host OS.

Before [[hardware-assisted virtualization]], guest operating systems ran under ring&nbsp;1. Any attempt that requires a higher privilege level to perform (ring&nbsp;0) will produce an interrupt and then be handled using software; this is called "Trap and Emulate".

To assist virtualization and reduce overhead caused by the reason above, VT-x and AMD-V allow the guest to run under Ring&nbsp;0. VT-x introduces VMX Root/Non-root Operation: The hypervisor runs in VMX Root Operation mode, possessing the highest privilege. Guest OS runs in VMX Non-Root Operation mode, which allows them to operate at ring&nbsp;0 without having actual hardware privileges. VMX non-root operation and VMX transitions are controlled by a data structure called a virtual-machine control.<ref>{{Cite book |url=https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-3c-part-3-manual.pdf |title=Intel® 64 and IA-32 Architectures Software Developer's Manual, Volume 3C |publisher=Intel Cooperation |year=2016 |publication-date=September 2016 |pages=1–3 |language=en}}</ref>  These hardware extensions allow classical "Trap and Emulate" virtualization to perform on x86 architecture but now with hardware support.

==Privilege level==
{{main | Privilege (computing) }}

A '''privilege level''' in the [[x86]] [[instruction set]] controls the access of the program currently running on the processor to resources such as memory regions, I/O ports, and special instructions.  There are 4 privilege levels ranging from 0 which is the most privileged, to 3 which is least privileged.  Most modern operating systems use level 0 for the kernel/executive, and use level 3 for application programs.  Any resource available to level n is also available to levels 0 to n, so the privilege levels are rings. When a lesser privileged process tries to access a higher privileged process, a [[general protection fault]] exception is reported to the OS.

It is not necessary to use all four privilege levels. Current [[operating system]]s with wide market share including [[Microsoft Windows]], [[macOS]], [[Linux]], [[iOS]] and [[Android (operating system)|Android]] mostly use a [[paging]] mechanism with only one bit to specify the privilege level as either Supervisor or User (U/S Bit). [[Windows NT]] uses the two-level system.<ref>{{cite book |last1=Russinovich |first1=Mark E. |first2=David A. |last2=Solomon |date=2005 |title=Microsoft Windows Internals |edition=4th |publisher=Microsoft Press |page=16 |isbn=978-0-7356-1917-3}}</ref>
The real mode programs in 8086 are executed at level 0 (highest privilege level) whereas virtual mode in 8086 executes all programs at level 3.<ref>{{cite book |author=Sunil Mathur |title=Microprocessor 8086: Architecture, Programming and Interfacing |edition=Eastern Economy |publisher=PHI Learning}}</ref>

Potential future uses for the multiple privilege levels supported by the x86 ISA family include [[Container (virtualization)|containerization]] and [[virtual machine]]s. A host operating system kernel could use instructions with full privilege access ([[kernel mode]]), whereas applications running on the guest OS in a virtual machine or container could use the lowest level of privileges in user mode. The virtual machine and guest OS kernel could themselves use an intermediate level of instruction privilege to invoke and [[virtualize]] kernel-mode operations such as [[system call]]s from the point of view of the guest operating system.<ref name="OSPP">{{cite book |last1=Anderson |first1=Thomas |last2=Dahlin |first2=Michael |title=Operating Systems: Principles and Practice |date=21 August 2014 |publisher=Recursive Books |chapter=2.2 |isbn=978-0985673529 |edition=2nd }}</ref>

===IOPL===
The '''IOPL''' ('''I/O Privilege level''') flag is a flag found on all IA-32 compatible [[x86 architecture|x86 CPUs]].  It occupies bits 12 and 13 in the [[FLAGS register]].  In [[protected mode]] and [[long mode]], it shows the I/O privilege level of the current program or task.  The Current Privilege Level (CPL) (CPL0, CPL1, CPL2, CPL3) of the task or program must be less than or equal to the IOPL in order for the task or program to access [[I/O port]]s.

The IOPL can be changed using <code>POPF(D)</code> and <code>IRET(D)</code> only when the current privilege level is Ring 0.

Besides IOPL, the [[Task State Segment#I.2FO Port Permissions|I/O Port Permissions]] in the TSS also take part in determining the ability of a task to access an I/O port.

===Miscellaneous===
In x86 systems, the x86 hardware virtualization ([[VT-x]] and [[Secure Virtual Machine|SVM]]) is referred as "ring&nbsp;−1", the [[System Management Mode]] is referred as "ring&nbsp;−2", the [[Intel Management Engine]] and [[AMD Platform Security Processor]] are sometimes referred as "ring&nbsp;−3".<ref>{{Cite web |last=De Gelas |first=Johan |title=Hardware Virtualization: the Nuts and Bolts |url=https://www.anandtech.com/show/2480 |access-date=2021-03-13 |website=AnandTech}}</ref>

==Use of hardware features==
Many CPU hardware architectures provide far more flexibility than is exploited by the [[operating system]]s that they normally run.  Proper use of complex CPU modes requires very close cooperation between the operating system and the CPU, and thus tends to tie the OS to the CPU architecture. When the OS and the CPU are specifically designed for each other, this is not a problem (although some hardware features may still be left unexploited), but when the OS is designed to be compatible with multiple, different CPU architectures, a large part of the CPU mode features may be ignored by the OS. For example, the reason Windows uses only two levels (ring 0 and ring 3) is that some hardware architectures that were supported in the past (such as [[PowerPC]] or [[MIPS architecture|MIPS]]) implemented only two privilege levels.<ref name="russinovich">{{cite book|last=Russinovich|first=Mark E.|author2=David A. Solomon|title=Microsoft Windows Internals|publisher=Microsoft Press|year=2005|edition=4|pages=[https://archive.org/details/isbn_9780735619173/page/16 16]|isbn=978-0-7356-1917-3|url-access=registration|url=https://archive.org/details/isbn_9780735619173/page/16}}</ref>

[[Multics]] was an operating system designed specifically for a special CPU architecture (which in turn was designed specifically for Multics), and it took full advantage of the CPU modes available to it.  However, it was an exception to the rule. Today, this high degree of interoperation between the OS and the hardware is not often cost-effective, despite the potential advantages for security and stability.

Ultimately, the purpose of distinct operating modes for the CPU is to provide hardware protection against accidental or deliberate corruption of the system environment (and corresponding breaches of system security) by software. Only "trusted" portions of system software are allowed to execute in the unrestricted environment of kernel mode, and then, in paradigmatic designs, only when absolutely necessary. All other software executes in one or more user modes. If a processor generates a fault or exception condition in a user mode, in most cases system stability is unaffected; if a processor generates a fault or exception condition in kernel mode, most operating systems will halt the system with an unrecoverable error. When a hierarchy of modes exists (ring-based security), faults and exceptions at one privilege level may destabilize only the higher-numbered privilege levels. Thus, a fault in Ring 0 (the kernel mode with the highest privilege) will crash the entire system, but a fault in Ring 2 will only affect Rings 3 and beyond and Ring 2 itself, at most.

Transitions between modes are at the discretion of the executing [[thread (computing)|thread]] when the transition is from a level of high privilege to one of low privilege (as from kernel to user modes), but transitions from lower to higher levels of privilege can take place only through secure, hardware-controlled "gates" that are traversed by executing special instructions or when external interrupts are received.

[[Microkernel]] operating systems attempt to minimize the amount of code running in privileged mode, for purposes of [[Computer security|security]] and [[elegance]], but ultimately sacrificing performance.

==See also==
* [[Call gate (Intel)]]
* [[Memory segmentation]]
* [[Protected mode]]{{snd}} available on x86-compatible 80286 CPUs and newer
* [[IOPL (CONFIG.SYS directive)]] – an OS/2 directive to run DLL code at ring 2 instead of at ring 3
* [[Segment descriptor]]
* [[Supervisor Call instruction]]
* [[System Management Mode]] (SMM)
* [[Principle of least privilege]]

==Notes==
{{notelist}}

==References==
{{Reflist}}

* Intel 80386 Programmer's Reference

==Further reading==
{{Div col|colwidth=30em}}
* {{cite thesis|type=MSc|author=David T. Rogers|url=https://calhoun.nps.edu/bitstream/handle/10945/919/03Jun_Rogers_David.pdf|title=A framework for dynamic subversion|publisher=[[Naval Postgraduate School]]|date=June 2003|hdl=10945/919}}
* {{cite web|author=William J. Caelli|url=https://cisse.info/resources/archives/category/25-papers?download=241:cael-2002|title=Relearning "Trusted Systems" in an Age of NIIP: Lessons from the Past for the Future.|date=2002|format=PDF|archive-url=https://web.archive.org/web/20150420221504/https://cisse.info/resources/archives/category/25-papers?download=241:cael-2002|archive-date=20 April 2015|url-status=dead}}
* {{cite conference|author1=Haruna R. Isa|author2=William R. Shockley|author3=Cynthia E. Irvine|url=https://calhoun.nps.edu/bitstream/handle/10945/7198/99paper_multithread.pdf?sequence=1&isAllowed=y|title=A Multi-threading Architecture for Multilevel Secure Transaction Processing|book-title=Proceedings of the 1999 IEEE Symposium on Security and Privacy|location=Oakland, CA|pages=166–179|date=May 1999|hdl=10945/7198}}
* {{cite web|author=Ivan Kelly|url=http://minixonxen.skynet.ie/cgi-bin/trac.cgi/attachment/wiki/Report/Report.pdf?format=raw|title=Porting MINIX to Xen|date=8 May 2006|archive-url=https://web.archive.org/web/20060827024930/http://minixonxen.skynet.ie/cgi-bin/trac.cgi/attachment/wiki/Report/Report.pdf?format=raw|archive-date=27 August 2006}}
* {{cite web|author1=Paul Barham|author2=Boris Dragovic|author3=Keir Fraser|author4=Steven Hand|author5=Tim Harris|author6=Alex Ho|author7=Rolf Neugebauer|author8=Ian Pratt|author9=Andrew Warfield|url=http://www.cl.cam.ac.uk/netos/papers/2003-xensosp.pdf|title=Xen and the Art of Virtualization|year=2003}}
* {{cite web|author1=Marcus Peinado|author2=Yuqun Chen|author3=Paul England|author4=John Manferdelli|url=https://research.microsoft.com/~yuqunc/papers/ngscb.pdf|title=NGSCB: A Trusted Open System|archive-url=https://web.archive.org/web/20050304033047/https://research.microsoft.com/~yuqunc/papers/ngscb.pdf|archive-date=4 March 2005}}
* {{cite web|author1=Michael D. Schroeder|author-link1=Michael D. Schroeder|author2=Jerome H. Saltzer|author-link2=Jerome H. Saltzer|url=http://www.multicians.org/protection.html|title=A Hardware Architecture for Implementing Protection Rings|year=1972}}
* {{cite web|url=http://download.intel.com/design/PentiumII/manuals/24319202.pdf|title=Intel Architecture Software Developer's Manual Volume 3: System Programming (Order Number 243192)|at=Chapter 4 "Protection"; section 4.5 "Privilege levels"|archive-url=https://web.archive.org/web/20090219054818/http://download.intel.com/design/PentiumII/manuals/24319202.pdf|archive-date=19 February 2009|url-status=dead}}
* {{cite conference|author1=Tzi-cker Chiueh|author2=Ganesh Venkitachalam|author3=Prashant Pradhan|book-title=Proceedings of the seventeenth ACM symposium on Operating systems principles |title=Integrating segmentation and paging protection for safe, efficient and transparent software extensions|date=December 1999|doi=10.1145/319151.319161|isbn=1581131402|s2cid=9456119|at=Section 3: Protection hardware features in Intel X86 architecture; subsection 3.1 Protection checks|doi-access=free}}
* {{cite web|author1=Takahiro Shinagawa|author2=Kenji Kono|author3=Takashi Masuda|url=https://www.is.s.u-tokyo.ac.jp/library/tech-reports/TR00-02-a4.pdf|title=Exploiting Segmentation Mechanism for Protecting Against Malicious Mobile Code|date=17 May 2000|at=Chapter 3 Implementation; section 3.2.1 Ring Protection|access-date=2 April 2018|archive-url=https://web.archive.org/web/20170810203311/http://www.is.s.u-tokyo.ac.jp/library/tech-reports/TR00-02-a4.pdf|archive-date=10 August 2017|url-status=dead}}
* {{cite conference|last1=Boebert|first1=William Earl|author2=R. Kain|title=A Practical Alternative to Hierarchical Integrity Policies|conference=8th National Computer Security Conference|date=1985}}
* {{cite journal|last1=Gorine|first1=Andrei|last2=Krivolapov|first2=Alexander|url=http://www.ddj.com/database/207401567|title=Kernel Mode Databases: A DBMS technology for high-performance applications|journal=[[Dr. Dobb's Journal]]|date=May 2008}}
{{div col end}}

{{Operating System}}

{{DEFAULTSORT:Ring (Computer Security)}}
[[Category:Central processing unit]]
[[Category:Computer security models]]
[[Category:Operating system technology]]