Why Intel is adding instructions to speed up non-volatile memory
1–10 of 45 posts
Re: Why Intel is adding instructions to speed up non-volatile memory
#2I've heard predictions that a significant portion of new x86 servers will be using non-volatile memory within the new 5-7 years.
Memory is becoming the new disk. This could have major security implications, as memory contents are unencrypted in general.
Fortunately, Intel CPUs will have hardware support to encrypt SGX enclaves. Perhaps that support can be used for general memory access as well.
Re: Why Intel is adding instructions to speed up non-volatile memory
#3I've heard predictions that a significant portion of new x86 servers will be using non-volatile memory within the new 5-7 years. Memory is becoming the new disk. This could have major security implications, as memory contents are unencrypted in general. Fortunately, Intel CPUs will have hardware support to encrypt SGX enclaves. Perhaps that support can be used for general memory access as well.
if non-volatile memory is becoming the new disk, why is it any more or less likely to be encrypted than current disk storage (mostly not, as far as I've seen).
Re: Why Intel is adding instructions to speed up non-volatile memory
#4I've heard predictions that a significant portion of new x86 servers will be using non-volatile memory within the new 5-7 years. Memory is becoming the new disk. This could have major security implications, as memory contents are unencrypted in general. Fortunately, Intel CPUs will have hardware support to encrypt SGX enclaves. Perhaps that support can be used for general memory access as well.
if non-volatile memory is becoming the new disk, why is it any more or less likely to be encrypted than current disk storage (mostly not, as far as I've seen).
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.
Re: Why Intel is adding instructions to speed up non-volatile memory
#5Computing really hasn't figured out how to handle non-volatile memory as yet. It's almost always used to emulate rotating disks, with file systems, named files, and a trip through the OS to access anything. Access times for non-volatile memory are orders of magnitude faster than disk access times, so small accesses are feasible. But that's not how it's treated under existing operating systems.
There are alternatives. Non-volatile memory could be treated as a key/value store, or a tree, with a storage controller between the CPU and the memory device. With appropriate protection hardware, this could be accessed from user space through special instructions. That's what I though this article indicated. But no. This is just better cache management for the OS.
Re: Why Intel is adding instructions to speed up non-volatile memory
#6Earlier quoted context omitted.
if non-volatile memory is becoming the new disk, why is it any more or less likely to be encrypted than current disk storage (mostly not, as far as I've seen).
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.
Re: Why Intel is adding instructions to speed up non-volatile memory
#7I've heard predictions that a significant portion of new x86 servers will be using non-volatile memory within the new 5-7 years. Memory is becoming the new disk. This could have major security implications, as memory contents are unencrypted in general. Fortunately, Intel CPUs will have hardware support to encrypt SGX enclaves. Perhaps that support can be used for general memory access as well.
if non-volatile memory is becoming the new disk, why is it any more or less likely to be encrypted than current disk storage (mostly not, as far as I've seen).
three words for you: cold boot attacks
Re: Why Intel is adding instructions to speed up non-volatile memory
#8Earlier quoted context omitted.
if non-volatile memory is becoming the new disk, why is it any more or less likely to be encrypted than current disk storage (mostly not, as far as I've seen).
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.
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.
Re: Why Intel is adding instructions to speed up non-volatile memory
#9Earlier quoted context omitted.
if non-volatile memory is becoming the new disk, why is it any more or less likely to be encrypted than current disk storage (mostly not, as far as I've seen).
three words for you: cold boot attacks
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.
Re: Why Intel is adding instructions to speed up non-volatile memory
#10Computing really hasn't figured out how to handle non-volatile memory as yet. It's almost always used to emulate rotating disks, with file systems, named files, and a trip through the OS to access anything. Access times for non-volatile memory are orders of magnitude faster than disk access times, so small accesses are feasible. But that's not how it's treated under existing operating systems. There are alternatives.…
It is already treated as a k/v store, where key is a LBA and the value is a 512/4096byte block. The OS builds everything else (ie. filesystems) on top of that. Applications can already now access the raw k/v store directly if they wish (open /dev/sd? directly, permissions allowing).