Long story short, memory bandwidth is much faster than the best x86 crypto implementations can handle.

Encrypting disks or network is no problem today, but we'll need architectural changes to support full memory encryption without a performance hit.

This could be done mostly transparently, with the encryption in the memory controller. Addresses and data are already scrambled with a (non-cryptographic) scrambling code for EMI reasons. Of course, a sufficiently fast hardware crypto core would be required.

EDIT: Also, I forgot that the last generation of consoles (and I assume the current) have transparent encryption of main memory.

Indeed, there is discussion of encrypted memory on the controller in Risc-V at http://lowrisc.org

How do you square that with the performance of the AES-NI instructions? That is theoretically 16 bytes per cycle from the manual. Per core. That is way in excess of memory bandwidth, even with DDR4.

The theoretical maximum for current chips is less than 16 bytes per cycle. On Haswell you can process (in parallel) 7 blocks in roughly the time it would take to process 1. The latency of each round is 7 cycles, a full AES-128 10 rounds is ~70 cycles, so effectively you can process at most 1.6 bytes per cycle, or 1.14 if you use 256-bit keys (ignoring the cost of key scheduling and overhead here).

Even if you dedicate all CPU cores to the task of encrypting memory, you still stop short of exceeding theoretical memory bandwidth by quite a bit.

Do you believe it's reasonable to assume that AES performance will remain constant over the same 5-7 year timeframe? That's at least a couple of hardware generations for an improvement they could make in the current generation if there was a market for it.

There is certainly room for improvement, but I don't see an 16x speedup happening on a 5-year horizon using the current AES-NI instruction set.

Ah, I was forgetting about rounds, you're correct that you won't be able to match the memory bandwidth then.

The VIA C7 AES implementation could keep up with memory (ca. 20Gb/s). With suitable cipher modes you can use multiple pipelined units in parallel with negligible overhead.

Or fast, strong, pipelined hardware encryption.

AES is not the best you could do there.

three words for you: cold boot attacks

No.

Remanence attacks are pointless against non-volatile media. You use them against volatile media in a physical attack in an attempt to sneak under/manipulate the limits of that volatility to cause violations of security assumptions, such as "the keys are in RAM" (true) > "RAM is instantly volatile on shutdown" (not quite true) > "keys are instantly zeroised on shutdown" (not this easily they're not).

Some RAM is much more volatile than conventional bulk SRAM or DRAM (for example, frequently L1/L2 caches on CPUs are impractical to exploit). Properly encrypt bulk data held in high-remenance or non-volatile RAM with a key held in such low-remanance RAM, and your security problem is solved.

That still doesn't answer the question. If you treat non-volatile memory as a disk, then the data would never touch it unencrypted, so a cold boot attack is useless against the non-volotile memory. Of course, you could still launch a cold boot attack on the volotile memory, but we can do that already.