4 ms·

>> - It lets you extract the sealing key and remote attestation. That's about as bad as it gets. It could have definitely been worse, with the leak of the fuse

>> - It lets you extract the sealing key and remote attestation. That's about as bad as it gets. It could have definitely been worse, with the leak of the fused secrets or a breach to integrity of the microcode (the two things that together constitute the TCB, which put simply is the only piece of the system you assume will never be broken). All in all, assuming a microcode update can counter the attack as Intel claims, sealing and attestation secrets will be rekeyed via the KDF rooted in the fused keys, so that you can start afresh. Of course, operationally speaking, that is a total pain but it is frankly remarkable to see this kind of deep recovery strategy finally built into consumer devices (and yes, I know DRM is unfortunately the main driver, but there are still some very legitimate use cases). >> flush L1d (or prevent things from accessing the same L1d via e.g. core pinning) and you're fine No, you are not fine. As the paper explains, an adversary (which is by definition more privileged than you are) can operate between the moment you use secrets in L1 and the moment you flush them out. Only the CPU (silicon or microcode) can assist you in the flushing of L1 when you exit enclave mode.

geogriffin 8y ago
Agreed. > Only the CPU (silicon or microcode) can assist you in the flushing of L1 when you exit enclave mode. This seems correct, upon double-checking. The interrupt process within SGX is called Asynchronous Enclave Exit (AEX) and does not give the enclave an opportunity to run any code upon interrupt, though it is possible to run code upon every enclave entry (via code placed at the Asynchronous Entry Pointer). I'm not sure that would help with any speculation-based exploits, however.
- lvh 8y ago
  There's more going on than just the SGX attack. What I'm not saying is "add this 1 instruction and everything is copacetic" -- what I am saying is that the patches for at least some of the vulnerabilities are somewhat straightforward.
lvh 8y ago
That's fair -- I was talking about a specific SGX enclave instance, not SGX in general. In particular, you're right that you can only leak things from an SGX instance, but you can't break all future SGX enclaves forever on a given CPU.
sabas123 8y ago
> No, you are not fine. As the paper explains, an adversary (which is by definition more privileged than you are) can operate between the moment you use secrets in L1 and the moment you flush them out. Only the CPU (silicon or microcode) can assist you in the flushing of L1 when you exit enclave mode. It gets worse, if the adversary has root they can force all the data in L1 cache. This allows them to read all memory pages of an executed and non-exuctuted encalve. There is nothing what can be done against this from the enclaves point of view.

geogriffin 8y ago

Agreed. > Only the CPU (silicon or microcode) can assist you in the flushing of L1 when you exit enclave mode. This seems correct, upon double-checking. The interrupt process within SGX is called Asynchronous Enclave Exit (AEX) and does not give the enclave an opportunity to run any code upon interrupt, though it is possible to run code upon every enclave entry (via code placed at the Asynchronous Entry Pointer). I'm not sure that would help with any speculation-based exploits, however.

lvh 8y ago
There's more going on than just the SGX attack. What I'm not saying is "add this 1 instruction and everything is copacetic" -- what I am saying is that the patches for at least some of the vulnerabilities are somewhat straightforward.

lvh 8y ago

That's fair -- I was talking about a specific SGX enclave instance, not SGX in general. In particular, you're right that you can only leak things from an SGX instance, but you can't break all future SGX enclaves forever on a given CPU.

sabas123 8y ago

> No, you are not fine. As the paper explains, an adversary (which is by definition more privileged than you are) can operate between the moment you use secrets in L1 and the moment you flush them out. Only the CPU (silicon or microcode) can assist you in the flushing of L1 when you exit enclave mode. It gets worse, if the adversary has root they can force all the data in L1 cache. This allows them to read all memory pages of an executed and non-exuctuted encalve. There is nothing what can be done against this from the enclaves point of view.