Differences
This shows you the differences between two versions of the page.
|
ass:cursuri:01:theory:02 [2023/07/16 20:22] florin.stancu [Processor protection domains] |
ass:cursuri:01:theory:02 [2023/07/17 22:39] (current) radu.mantu |
||
|---|---|---|---|
| Line 49: | Line 49: | ||
| - **Ring -4:** A [[https://i.blackhat.com/us-18/Thu-August-9/us-18-Domas-God-Mode-Unlocked-Hardware-Backdoors-In-x86-CPUs-wp.pdf|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. | - **Ring -4:** A [[https://i.blackhat.com/us-18/Thu-August-9/us-18-Domas-God-Mode-Unlocked-Hardware-Backdoors-In-x86-CPUs-wp.pdf|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. | ||
| </spoiler> | </spoiler> | ||
| + | \\ | ||
| Finally, please note that, although we described the virtual memory mechanisms of x86, the concepts are really the same for all other architectures (of course, the configuration registers and page entry structure will differ, but they all share a common feature set)! | Finally, please note that, although we described the virtual memory mechanisms of x86, the concepts are really the same for all other architectures (of course, the configuration registers and page entry structure will differ, but they all share a common feature set)! | ||
| Line 54: | Line 55: | ||
| === ARM exception levels === | === ARM exception levels === | ||
| - | In ARM's nomenclature, the CPU protection modes are called Exception Levels. Although they are analogous to x86's rings, they feature two significant improvements: first, the standardization of the most important modes for userspace, kernel space and hypervisor (for running multiple OSes in Virtual Machines); second, a secure separation between Secure and Non-Secure Worlds, as it will be discussed in [[:ass:cursuri:03|Lecture 03]]. | + | In ARM's nomenclature, the CPU protection modes are called Exception Levels. Although they are analogous to x86's rings, they feature two significant improvements: first, the standardization of the most important modes for userspace, kernel space and hypervisor (for running multiple OSes in Virtual Machines); second, a secure separation between Secure and Non-Secure Worlds, but this will be discussed in [[:ass:cursuri:03|Lecture 03]]. |
| {{ :ass:laboratoare:01:theory:arm_exception_levels.png?700 |}} | {{ :ass:laboratoare:01:theory:arm_exception_levels.png?700 |}} | ||
| <html><center> | <html><center> | ||
| - | <b>Figure 1:</b> ARM Exception Levels. | + | <b>Figure 2:</b> ARM Exception Levels. |
| </center></html> | </center></html> | ||
| - | The Non-Secure world consists of three exception levels: | + | Usually, there are three exception levels: |
| - | * **NS-EL0:** User Space (ring3) | + | * **EL0:** User Space (equiv to //Ring 3// from x86); |
| - | * **NS-EL1:** Kernel Space (ring0) | + | * **EL1:** Kernel Space (%%~%%//Ring 0//); |
| - | * **NS-EL2:** Hypervisor (ring-1) | + | * **EL2:** Hypervisor (%%~%%//Ring -1//); notably absent from the Secure World; |
| + | |||
| + | But, with the introduction of the ARM TrustZone security extensions, [almost] all of these modes were vertically partitioned into two security domains. | ||
| + | To make it possible to switch between them, a new Exception Level -- **EL3** (the Secure Monitor) -- was added. | ||
| + | |||
| + | <spoiler Bonus: if can't wait until Lecture 03 in order to find out about ARM's Trusted Execution features, expand!> | ||
| + | On the Secure World side, we've got: | ||
| - | <hidden> | ||
| - | 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-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. | * **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. | ||
| Line 73: | Line 78: | ||
| Although chances are you haven't heard of it, Intel had a similar solution called the [[https://eprint.iacr.org/2016/086.pdf|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. | Although chances are you haven't heard of it, Intel had a similar solution called the [[https://eprint.iacr.org/2016/086.pdf|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. | ||
| - | </hidden> | + | |
| + | </spoiler> | ||
| + | |||
| + | \\ | ||
| + | \\ | ||
