4 ms·

This is _bananas_. - Unlike previous speculative execution attacks against SGX, this extracts memory "in parallel" to SGX, instead of attacking the code runnin

by lvh 8y ago

This is _bananas_. - Unlike previous speculative execution attacks against SGX, this extracts memory "in parallel" to SGX, instead of attacking the code running in SGX directly. It always works: it doesn't require the SGX code to run and it doesn't require it to have any particular speculative execuction vulnerability. This also means existing mitigations like retpolines don't work. - It lets you extract the sealing key and remote attestation. That's about as bad as it gets. Because SGX is primarily about encrypting RAM, anything that pops L1 cache is game over and this is a stark reminder of that fact. - The second attack that fell out of this allows you to read arbitrary L1 cache memory, across kernel-userspace or even VM lines. The good news here is that the mitigation is somewhat straightforward. It's a pure L1d attack: flush L1d (or prevent things from accessing the same L1d via e.g. core pinning) and you're fine. If there was any doubt left that speculative execution bugs were an entire new class and not just a one-off gimmick...

zimmerfrei 8y ago
>> - 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.

by lvh 8y ago

zimmerfrei 8y ago

>> - 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.