https://www.felixcloutier.com/x86/
↑ Check x86 instructions (incl. SGX-related instructions like EENTER)
Spectre / Meltdown
Modern CPUs all support instruction pre-fetch and pre-execution. Consider the following code snippet.
raise_exception();
/* Naughty things happen here! CPU exeuctes this instruction before
`raise_exception`!
*/
access(probe_data[addr_in_kernel]);
Say we want to access a kernel address addr_in_kernel from user space. By design, the kernel will throw segmentation fault because the user space application is accessing invalid memory pages, but what if we trap the application into kernel space? The CPU executes access while raise_exception traps into the kernel; thus the addr_in_kernel is valid now and the content is loaded into the CPU cache. When the instruction finishes, we can check the access latency of probe_data. Similarly,
if(index1 < array_a_size) {
index2 = array_a[index1];
if(index2 < array_b_size) {
value = array_b[index2];
}
}
allows the attack, too.
A mitigation is to use lfence to force all the instructions before this instruction are properly executed.
__raise();
/* Gaurdian */
__builtin_ia32_lfence();
secret_operations();
The CPU cache enables for fast data retrieval that strikes between storage and locality. Thus, the attacker can mount inferences based on the information whether the target data is stored in the cache by measuring the execution time of the enclave. Intuitively, if the attacker deliberately construct a CPU cache filled with some sort of specific data, then the enclave would have finished in an expected time duration; if the attacker modifies the cache and reload the enclave, then the execution time would be different from the previous one, and she could repeat until sufficient sensitive information has been leaked. This is somehow like the differential crypto-analysis.
Misc: https://lviattack.eu/
SGX-STEP:
ioctl.