AMD Secure Memory Encryption is not vulnerable to rowhammer attacks ?

[William Gaatjes]

I was wondering about this with the recent speculative execution in mind.
With a load store architecture, one can only access the memory through load and store instructions.
So those instructions and processor state modifying instructions need to be constantly checked for privileges.
At least that is the impression i get.
But x86 is a memory register architecture. That means that any instruction that can also do a memory access needs to be checked and all processor state modifying instructions.


Thoughts ?


edit:
Edited the title to reflect the more interesting discussion.

 

[DaveSimmons]

Either one could have bugs or design flaws that make information leaks or privilege escalation possible in real-world implementations. I think the Row Hammer attack showed that simple reasoning using abstract models about what is and isn't safe is now incomplete.

 

[William Gaatjes]

Either one could have bugs or design flaws that make information leaks or privilege escalation possible in real-world implementations. I think the Row Hammer attack showed that simple reasoning using abstract models about what is and isn't safe is now incomplete.

Row hammer is about closely packed dram cell weakness. One can even do it with flash cells as well. Sram cells, i am not so sure they are vulnerable for rowhammer attacks.
Processes with larger features are less vulnerable, 180nm is much less if not at all vulnerable compared to 14nm. But that translates into smaller amount of total memory per die.

 

[William Gaatjes]

I kind of meant that a load store architecture has less instructions to do boundary checks for in comparison to a memory register architecture.
In theory, it should be simpler because of less instructions to test and thus more easy to capture any problematic situation.

But if it both architectures are taken as a system that is translated through a decoder in a sort of universal uop OOe statemachine, yeah... Then it would not matter.
i mean when we look at all affected architectures, do they not all look very much alike ?

Why are some arm design not vulnerable, but the latest performant ones that look like a x86 core are ?
There is the interesting information to be found.

 

[DaveSimmons]

The "meltdown" exploit is from information leaking through measuring performance changes even though the kernel memory accesses are properly blocked: https://arstechnica.com/gadgets/201...odern-processor-has-unfixable-security-flaws/

That's what I was getting at with Row Hammer. You could have OS and CPU memory controller designs that were both formally proven to never let you read or set other memory, only to have physics let you do it through side effects in the real-world implementation. I have no idea whether the OS and CPU were proven correct, my point is that even if from a formal logic point of view the memory was 100% protected, the real world said otherwise.

Similarly, you could prove that the kernel information was 100% safe from formal logic reasoning about the guards on memory accesses, only to have someone come up with the side channel leak of spotting timing differences in the kernel accesses that were accepted, based on the calls that were blocked.

To me these modern exploits are similar to other indirect attacks like bouncing a laser off window glass, recording keyboard clicks, looking at wear patterns on keypads, etc.: The system design might be safe when you only look at the logic of the design, but it isn't safe because of information leakage through side effects.

Long story long, I'd say either one could have nasty exploits that no one considered in the past and that do not come from logic or coding/engineering errors in the design.

 

[William Gaatjes]

With rowhammer exploits, that got me wondering.
AMD TSME in EPYC and in the ryzen pro cpu's should maybe be able to detect any rowhammer attack.
If the AES decryption could also detect if data has been altered and generate some sort of cpu exception when the memory is altered, AMD pro cpu's should not be vulnerable to rowhammer attacks.
But that depends on the ability to detect bit changes in the external dram through the AES decryptor.
I do not know if it can or not.

https://www.anandtech.com/show/1159...anced-security-longer-warranty-better-quality

To explain what TSME is, it makes sense to refer to AMD’s Zen memory encryption technologies in general. The Zen microarchitecture features two important technologies: Secure Memory Encryption (SME) and Secure Encrypted Virtualization (SEV) that protect data in DRAM using a dedicated AES-128 engine.
When data is stored on storage devices, it is usually encrypted, but when it is being processed on a CPU or temporarily stored in RAM, it is almost never is, leaving open the possibility of snooping these unprotected areas. As the name suggests, Secure Memory Encryption encrypts content of DRAM in a bid to eliminate data snooping by unauthorized programs or administrators (this is more likely to happen in a server/datacenter environment, but still). This feature will be particularly important for NVDIMMs going forward as they store data even after unplugged from their hosts.

The SME encrypts data when it is written to DRAM and decrypts it when it is read. The AES-128 key is generated by a NIST SP 800-90-compliant hardware RNG and then managed by the AMD-SP hardware (thus, in a secure environment only). Although a dedicated engine performs the encryption/decryption, the process still takes time and thus adds latency to memory accesses. AMD claims that the actual performance impact is not significant, but we will have to test it ourselves before making any conclusions of our own. AMD’s Zen microarchitecture supports full and partial memory encryption for cases when performance is a concern. The one downside to this is that both partial and full encryption modes will require OSes and software to be modified in order to work properly.

More practical for daily workstation use is AMD’s Transparent SME mode. As the name impies, Transparent mode is transpartent to OSes and programs, and thus be used with legacy software. Transparent SME mode stil encrypts DRAM completely, and this mode can be enabled from BIOS. At this point Transparent SME is the only type of SME supported by the Ryzen Pro, but AMD’s EPYC processors support all of them.

 

[DaveSimmons]

Interesting. If it uses checksums it could detect a single bit change, but for speed it might just encrypt / decrypt N byte chunks. Then a Row Hammer type exploit could corrupt RAM, but the corruption would be decrypted into something completely different making storing any specific attack code or data very difficult.

CPU: store "12345678" > AES > "abcdefgh" > RAM
{ Row Hammer > "Bbcdefgh" }
CPU: fetch "puffin42" < AES < "Bbcdefgh" < RAM

The exploit could still cause problems, just unpredictable ones instead of jumping into exploit code.

 

[William Gaatjes]

Yeah, it would make sense it can detect if the encrypted data has gone bad. But that would indeed mean it would store not just the encrypted data but also some kind of checksum. Memory for the application would then be less but a small price for total security.
Then again, if the ECC bits are encrypted as well with the data and as total stored in ram, the chance is more likely bit faults would be discovered during decryption and row hammer is not or almost not possible.

If it is just a means to prevent intrusion, but i cannot imagine that. Maybe there is something to find about how it works.

 

[William Gaatjes]

It does seem to work on a page basis.

 

[Thala]

I was wondering about this with the recent speculative execution in mind.
With a load store architecture, one can only access the memory through load and store instructions.
So those instructions and processor state modifying instructions need to be constantly checked for privileges.
At least that is the impression i get.
But x86 is a memory register architecture. That means that any instruction that can also do a memory access needs to be checked and all processor state modifying instructions.
Thoughts ?

Your picture of the HW architecture is wrong. It is not the instruction which is checked but the memory access. With other words a complex instruction with a memory access is broken down into memory access and ALU operation. The unit within the CPU, which is checking access permission on load and stores does not care which instruction was the origin. In fact all the information about a memory access is available in the page tables (which are cached in the TLBs) - namely access permissions, memory types and parts of the physical address.

In the big picture, of course, x86 ISA is much more complex to handle in the microarchitecture than a load/store/RISC ISA but there is no inherent disadvantage with respect to security.
In addition a memory access is much more expensive from energy perspective than a register access. This is another weakness of x86/x64 compared to say ARMv8.

 

[Thala]

If the AES decryption could also detect if data has been altered and generate some sort of cpu exception when the memory is altered, AMD pro cpu's should not be vulnerable to rowhammer attacks.

AES is no error correcting/detecting code. For single bit error detection you need a code with at least distance 2 (like Parity or CRC-1) and for single bit error correction you needs a code with at least distance 3 (like Hamming). Since Hamming is easy to implement in HW, ECC typically employs Hamming coding.

 

[William Gaatjes]

Your picture of the HW architecture is wrong. It is not the instruction which is checked but the memory access. With other words a complex instruction with a memory access is broken down into memory access and ALU operation. The unit within the CPU, which is checking access permission on load and stores does not care which instruction was the origin. In fact all the information about a memory access is available in the page tables (which are cached in the TLBs) - namely access permissions, memory types and parts of the physical address.

In the big picture, of course, x86 ISA is much more complex to handle in the microarchitecture than a load/store/RISC ISA but there is no inherent disadvantage with respect to security.
In addition a memory access is much more expensive from energy perspective than a register access. This is another weakness of x86/x64 compared to say ARMv8.

Well, take it up with AMD themselves.
The picture is from a pdf from them:
https://developer.amd.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf
I am sure AMD knows their hardware...

edit:
This is not an alu as you see it because of the symbol. This is just a block that is between the cpu and the memory.

 

[William Gaatjes]

AES is no error correcting/detecting code. For single bit error detection you need a code with at least distance 2 (like Parity or CRC-1) and for single bit error correction you needs a code with at least distance 3 (like Hamming). Since Hamming is easy to implement in HW, ECC typically employs Hamming coding.

Yesterday we were already already discussing how this might work and of course ECC is included. It is a PRO system. just do not know how.
For safety reason, it might be handy to als include the ECC bits in the encryption/decryption.
But we do not know.

edit:
Forgot to mention that the encryption/decryption unit is fully integrated into the memory controller.