Differences
This shows you the differences between two versions of the page.
|
ass:cursuri:01:theory:02 [2023/07/16 20:33] 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 63: | Line 64: | ||
| Usually, there are three exception levels: | Usually, there are three exception levels: | ||
| * **EL0:** User Space (equiv to //Ring 3// from x86); | * **EL0:** User Space (equiv to //Ring 3// from x86); | ||
| - | * **EL1:** Kernel Space (''~'' //Ring 0//); | + | * **EL1:** Kernel Space (%%~%%//Ring 0//); |
| - | * **EL2:** Hypervisor (''~''//Ring -1//); notably absent from the Secure World; | + | * **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. | 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. | To make it possible to switch between them, a new Exception Level -- **EL3** (the Secure Monitor) -- was added. | ||
| - | <spoiler Bonus: if you don't want to wait until Lecture 03 in order to find out about ARM's Trusted Execution features, expand!> | + | <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: | On the Secure World side, we've got: | ||
| Line 77: | 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. | ||
| + | |||
| </spoiler> | </spoiler> | ||
| - | <div style="margin-top: 1em;"> </div> | + | \\ |
| + | \\ | ||
