Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Intel is adding instructions to speed up non-volatile memory

danluu.com

Post reply on HN
Print view View original

11–20 of 45 posts

Re: Why Intel is adding instructions to speed up non-volatile memory

#11

Post by AlyssaRowan »

justcommenting wrote: post #7
ams6110 wrote: post #3

Earlier 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

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.

Re: Why Intel is adding instructions to speed up non-volatile memory

#12

Post by bahahah »

There are several storage class memories that are nearing commercialization. Intel is betting big on at least one of them. Most technologies in this class are orders of magnitude faster and have orders of magnitude better endurance than flash memory, while being only slightly slower the DRAM, yet non-volatile.

It is plausible that with another layer of in-package cache they could eliminate DRAM altogether, replacing it with ultrafast NVM. Imagine the resume/suspend speed and power savings of a machine whose state is always stored in NVM.

Re: Why Intel is adding instructions to speed up non-volatile memory

#13

Post by dfryer »

Animats wrote: post #5

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

This is not (specifically) for the OS. This is for non-volatile memory that is directly attached to the memory bus. The OS can then directly map NVRAM into the address space of a user-space process; the application could use these instructions to efficiently ensure the crash consistency of its persistent data.

Re: Why Intel is adding instructions to speed up non-volatile memory

#14

Post by pbsd »

eloff wrote: post #8
sweis wrote: post #4

Earlier quoted context omitted.

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.

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.

Re: Why Intel is adding instructions to speed up non-volatile memory

#15

Post by unwind »

Very interesting! It's always fun to see "external" development in the general field of computer architecture affect low-level stuff like a CPU's cache and memory subsystems.

It wasn't super-easy to figure out who in the grand ecosystem view of things is going to have to care about these instructions, but I guess database and OS folks.

Also, if the author reads this, the first block quote with instruction descriptions has an editing fail, it repeats the same paragraph three times (text begins "CLWB instruction is ordered only by store-fencing operations").

Re: Why Intel is adding instructions to speed up non-volatile memory

#16

Post by fleitz »

bahahah wrote: post #12

There are several storage class memories that are nearing commercialization. Intel is betting big on at least one of them. Most technologies in this class are orders of magnitude faster and have orders of magnitude better endurance than flash memory, while being only slightly slower the DRAM, yet non-volatile. It is plausible that with another layer of in-package cache they could eliminate DRAM altogether, replacing…

Is this basically memristors coming to market or are memristors still a few years off?

Re: Why Intel is adding instructions to speed up non-volatile memory

#17

Post by zurn »

Animats wrote: post #5

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

There have been systems where everything is memory mapped and disks are just used to emulate more memory.

It's called "single-level store" in System 36 and descendants. File access in Multics was all memory mapped.

There's nothing inherently rotating-disky about current filesystem APIs from the user point of view, a they just provide a database interface which has a certain type of namespace system for access. The block level part is largely invisible to the FS users (modulo leaky abstractions).

Re: Why Intel is adding instructions to speed up non-volatile memory

#18

Post by harshreality »

Animats wrote: post #5

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

Can't use current flash chips in that way, because write endurance.

Re: Why Intel is adding instructions to speed up non-volatile memory

#19

Post by AlyssaRowan »

sweis wrote: post #4
ams6110 wrote: post #3

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

Or fast, strong, pipelined hardware encryption.

AES is not the best you could do there.

Re: Why Intel is adding instructions to speed up non-volatile memory

#20

Post by justincormack »

WallWextra wrote: post #6
sweis wrote: post #4

Earlier quoted context omitted.

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
Post reply on HN