Working on x86-64, you may be familiar with its protection rings, or at least with two of them. When the architecture was first introduced in the late '70s, the designers expected OS developers to need a mechanism to isolate critical components (e.g.: drivers) from regular applications. As a result, they implemented four levels of isolation… that the OS developers more or less ignored:

• Ring 3: What you know as User Space. Access to certain privileged instructions such as RDMSR - Read Model Specific Register is restricted. Other like RDPMC - Read Performance Monitor Counter can be enabled even in ring3, but this is more of an exception, rather than the norm.
• Ring 2: Originally meant to host I/O drivers. While it was used for that in some operating systems (e.g. IBM's OS/2 from 1987) today it not longer serves any purpose.
• Ring 1: This was supposed to host drivers, separating them from the core systems of the kernel. Although similar to ring2 in that it no longer severs this purpose, some virtual machines such as VirtualBox use it to host the guest operating system.
• Ring 0: Also known as kernel space. Code running in this processor mode has (mostly) unrestricted access to the hardware.

The reason why ring1 and ring2 lost favor among kernel developers is mostly due to another component of the modern protection model, namely paging (see Fig. 1). Paging is a system that allows the Operating System to present each process a different view of its memory. When said process tries to access a page (i.e.: 4KB block), the address is translated by the Memory Management Unit (MMU), a hardware component, by means of a data structure called Page Table, unique to each process and residing in kernel memory. This allows the kernel to obscure parts of memory (e.g.: that of other processes) as a means of isolation. Or to over-commit resources, only to actually allocate them when needed (e.g.: malloc()-ed memory is assigned to the process only after it is first accessed).

Because changing the active Page Table is an expensive operation (mostly due to CPU cache invalidation), the Virtual Address Space of each process also contains the kernel memory mapped in the higher half. Yes, the kernel also uses virtual addressing for its own memory. When the kernel needs to intervene on behalf of the unprivileged process (e.g.: when a System Call is performed), the CPU state transitions from ring3 to ring0, but the Page Table does not need to be switched out. Although this technique increases the overall system performance, it also raises a question: how do we stop an unprivileged process from accessing kernel memory, since it's already mapped in its virtual address space?

Aside from information relevant to the address translation itself, the Page Table also contains access restrictions. Each memory transaction that leads to an address translation also presents its intent, e.g.: whether it wants to write data to memory, or fetch an instruction to execute. This allows the MMU to block such access depending on the Read-Write-Execute permissions associated with each page. However, this is only one example of restriction that can be enforced. The Page Table can also restrict access based on privilege levels. Unfortunately, the architecture defines only two such levels: privileged (ring0-2) and unprivileged (ring3).

By now it should start becoming clear why ring1 and ring2 were abandoned. Since the same isolation guarantees that User Space and Kernel Space enjoy could not be extended to each protection domain, sacrificing performance only to restrict access to a few privileged instructions was simply not worth it. Nonetheless, ring1 and ring2 are still implemented on x86 CPUs to this day. The reason? Based the announcement of the new x86s architecture that's supposed to eliminate 16-bit and 32-bit modes of 64-bit processors, it's safe to rule out backward compatibility. The real reason is probably that it's just cheaper this way.

Because a CPU architecture never stops evolving, new protection modes and extensions had to be added along the way. Some more unnerving than others:

1. Ring -1: The Hypervisor Mode. A CPU state that integrates with other extensions (e.g.: Two Stage Address Translations, IOMMU) in order to manage guest Virtual Machines more efficiently.
2. Ring -2: The System Management Engine. When entering this mode, the execution of any currently running program (including the Hypervisor) is suspended. Control is passed either to an alternate OS usually residing in proprietary firmware, or to a hardware debugger.
3. Ring -3: The Intel Management Engine is a co-processor that is always active as long as the motherboard has a power source (not even line power; the internal battery is sufficient). Although its functionality is not publicly documented, reverse engineers have figured out that it enforces Verified Boot and has DRM and TPM functionalities.
4. Ring -4: A deeply embedded core that was discovered in some Intel CPUs and was presented at BlackHat 2018. This is essentially a hidden co-processor that shares an execution pipeline and some of its registers with the main processor. A transition to this mode can be performed from by a knowledgeable attacker from any privilege levels, including ring3. While in ring-4, the executing (normally unprivileged code) presumably has access to all system resources, similarly to ring-3.

In ARM's nomenclature, the protection modes are called Exception Levels. Although they are analogous to the (important) protection rings in x86, they benefit from one significant improvement: the separation of Secure and Non-Secure Worlds. Depending on the system configuration, access to certain resources (both memory and physical devices) can be restricted to Secure World code.

The Non-Secure world consists of three exception levels:

• NS-EL0: User Space (ring3)
• NS-EL1: Kernel Space (ring0)
• NS-EL2: Hypervisor (ring-1)

Nothing interesting here; it's the same as x86. On the Secure World side however:

• S-EL0: In this mode, Trusted Applications (TA) are being executed. TAs are system-critical functions that can be invoked from anywhere in the Non-Secure World (e.g.: encrypting application data when it needs to be saved to persistent storage; can be done explicitly by the application or implicitly by the kernel driver). We'll take a look at how TAs are written in the second lab.
• S-EL1: This is the Trusted OS. Similarly to a regular OS, it manages access to (some) devices such as the Trusted Platform Module (TPM). Additionally, it must be able to interpret TA invocations from the Non-Secure World while providing the TAs functionalities similar to what Linux offers to its processes via system calls. For example, if a TA wants to open a file in a secure disk partition, by running in user space it will not have direct access to the File System Layer or the underlying block device. Secure or Non-Secure, it still runs in an unprivileged processor state, without access to the hardware.
• EL3: The Secure Monitor acts as a bridge between the Secure and Non-Secure Worlds. All TA invocations are performed by means of a Secure Monitor Call (SMC). Think of SMCs as a system calls that instead of transitioning from EL0 to EL1, they reach the TAs the following way: NS-EL0 → NS-EL1 → NS-EL2 → EL3 → S-EL1 → S-EL0.

Although chances are you haven't heard of it, Intel had a similar solution called the Software Guard Extension (SGX). This extension was meant to protect small amounts (~72MB) of sensitive (user space) application data and code from a potentially malicious OS. This was realized by restricting access to the protected memory ranges (Enclaves) to code that already resided in the Enclave. Additionally, calls to Enclave functions could be made only via a strictly enforced API defined by the user at compile time; so no arbitrary jumps after a return to libc. There are numerous reasons why this technology failed. The main one would be that it did not work. Researchers have found dozens of ways to break the isolation guarantees that SGX was supposed to offer, most of them relying on side channels attacks (i.e.: deducing user secrets by observing how the target process influences the system). Coupled with the lack of isolation for privileged code that ARM offers (S-EL1) and the fact that Intel's remote attestation of SGX-capable CPUs and secure applications could not be offloaded to third parties, more or less guaranteed its fade from relevance.