4 ms·

I wonder to what extent the encrypted memory enclaves in modern CPUs can mitigate these kinds of attacks. If the data stored in the physical memory has been en

I wonder to what extent the encrypted memory enclaves in modern CPUs can mitigate these kinds of attacks. If the data stored in the physical memory has been encrypted using a randomly generated secret key by the memory controller on the CPU, it should be impossible to generate an exact target data pattern in the victim even when the aggressor and victim are in the same enclave. That in itself isn't sufficient to guard against all attacks, because the memory enclaves don't provide data integrity, only encryption. So if all you're trying to do is to change a victim's boolean that controls whether you have e.g. root access, then changing that boolean from false (0) to true (any non-zero value) is going to succeed with high probability despite the encryption. Still, maybe there's an angle here that can help put an end to Rowhammer once and for all in a few hardware generations?

anonymousDan 8y ago
Enclaves do have integrity protection (at least SGX does).
- atq2119 8y ago
  Do you have details on that? The only references I see to integrity on Intel's own overview site are for data at rest (i.e. stored on disk or in network transit etc.). This is easy to achieve and plausible with cryptographic signatures, and both AMD and Intel have some form of this. The reason I'm doubting that there's integrity protection for data while in RAM is that it's information-theoretically impossible to do that without memory overhead. This doubt seems to be confirmed by the descriptions of the ELDB/ELDU/EWB instructions: they perform cryptographic authentication while copying pages to and from the enclave. There don't seem to be any integrity checks while data is live in the enclave -- and that's what matters for Rowhammer protection.
  - ctz 8y ago
    https://eprint.iacr.org/2016/204.pdf https://eprint.iacr.org/2016/204.pdf (paper) https://rwc.iacr.org/2016/Slides/RWC_2016_Gueron_2016_01_08.pdf https://rwc.iacr.org/2016/Slides/RWC_2016_Gueron_2016_01_08.... (talk slides from RWC 2016)
  - posi 8y ago
    There's a ton of overhead. SGX uses encrypted ram, if that helps your mental state
  - anonymousDan 8y ago
    There is a memory encryption engine on each CPU that transparently encrypts and integrity protects each cache line as it flows to and from main memory. The integrity protection info is stored in a tree -like structure in part of one of the on CPU caches. The storage overhead for this data structure is one of the reasons the maximum enclave size is currently limited to about 100MB, although rumour has it that limitation will be removed in future generations. In saying all that, I would be very interested to hear ideas you might have on how Rowhammer could bypass SGX :)
Confiks 8y ago
On the subject of RAM encryption, there's even an kernel modification that (ab)uses the x86 debug registers to store are AES key and transparently encrypts / decrypts RAM; Tresor. > That [encrypted memory] in itself isn't sufficient to guard against all attacks You might want to read about authenticated encryption [2]. The authenticity of the decrypted data often lies in the block cipher mode (for example OBS) rather than the block primitive, where Tresor uses the AES-NI instruction. I would imagine SGX does something along the same lines. [1] https://www.usenix.org/legacy/event/sec11/tech/full_papers/Muller.pdf https://www.usenix.org/legacy/event/sec11/tech/full_papers/M... [2] https://en.wikipedia.org/wiki/Authenticated_encryption https://en.wikipedia.org/wiki/Authenticated_encryption
- BeeOnRope 8y ago
  TRESOR doesn't have anything to do with encrypting RAM - it's just a tweak to existing disk encryption methods which stores the encryption key in a debug register, rather than RAM. This gives resistance against attackers trying to break your disk encryption by trying to read your key directly from RAM.
  - Confiks 8y ago
    Yes, indeed. Thanks for correcting that.
amluto 8y ago
On SGX, I believe the general model is that the CPU doesn’t trust the physical memory backing the enclave at all. But I suspect that the CPU will detect the attack and disable SGX entirely, systemwide, until a reboot.

anonymousDan 8y ago

Enclaves do have integrity protection (at least SGX does).

atq2119 8y ago
Do you have details on that? The only references I see to integrity on Intel's own overview site are for data at rest (i.e. stored on disk or in network transit etc.). This is easy to achieve and plausible with cryptographic signatures, and both AMD and Intel have some form of this. The reason I'm doubting that there's integrity protection for data while in RAM is that it's information-theoretically impossible to do that without memory overhead. This doubt seems to be confirmed by the descriptions of the ELDB/ELDU/EWB instructions: they perform cryptographic authentication while copying pages to and from the enclave. There don't seem to be any integrity checks while data is live in the enclave -- and that's what matters for Rowhammer protection.
- ctz 8y ago
  https://eprint.iacr.org/2016/204.pdf https://eprint.iacr.org/2016/204.pdf (paper) https://rwc.iacr.org/2016/Slides/RWC_2016_Gueron_2016_01_08.pdf https://rwc.iacr.org/2016/Slides/RWC_2016_Gueron_2016_01_08.... (talk slides from RWC 2016)
- posi 8y ago
  There's a ton of overhead. SGX uses encrypted ram, if that helps your mental state
- anonymousDan 8y ago
  There is a memory encryption engine on each CPU that transparently encrypts and integrity protects each cache line as it flows to and from main memory. The integrity protection info is stored in a tree -like structure in part of one of the on CPU caches. The storage overhead for this data structure is one of the reasons the maximum enclave size is currently limited to about 100MB, although rumour has it that limitation will be removed in future generations. In saying all that, I would be very interested to hear ideas you might have on how Rowhammer could bypass SGX :)

Confiks 8y ago

On the subject of RAM encryption, there's even an kernel modification that (ab)uses the x86 debug registers to store are AES key and transparently encrypts / decrypts RAM; Tresor. > That [encrypted memory] in itself isn't sufficient to guard against all attacks You might want to read about authenticated encryption [2]. The authenticity of the decrypted data often lies in the block cipher mode (for example OBS) rather than the block primitive, where Tresor uses the AES-NI instruction. I would imagine SGX does something along the same lines. [1] https://www.usenix.org/legacy/event/sec11/tech/full_papers/Muller.pdf https://www.usenix.org/legacy/event/sec11/tech/full_papers/M... [2] https://en.wikipedia.org/wiki/Authenticated_encryption https://en.wikipedia.org/wiki/Authenticated_encryption

BeeOnRope 8y ago
TRESOR doesn't have anything to do with encrypting RAM - it's just a tweak to existing disk encryption methods which stores the encryption key in a debug register, rather than RAM. This gives resistance against attackers trying to break your disk encryption by trying to read your key directly from RAM.
- Confiks 8y ago
  Yes, indeed. Thanks for correcting that.

amluto 8y ago

On SGX, I believe the general model is that the CPU doesn’t trust the physical memory backing the enclave at all. But I suspect that the CPU will detect the attack and disable SGX entirely, systemwide, until a reboot.