Chasing AMD, Intel Promises Full Memory Encryption in Upcoming CPUs
Published on March 01, 2020 at 12:04AM
"Intel's security plans sound a lot like 'we're going to catch up to AMD,'" argues FOSS advocate and "mercenary sysadmin" Jim Salter at Ars Technica, citing a "present-and-future" presentation by Anil Rao and Scott Woodgate at Intel's Security Day that promised a future with Full Memory Encryption but began with Intel SGX (launched with the Skylake microarchitecture in 2015). Salter describes SGX as "one of the first hardware encryption technologies designed to protect areas of memory from unauthorized users, up to and including the system administrators themselves." SGX is a set of x86_64 CPU instructions which allows a process to create an "enclave" within memory which is hardware encrypted. Data stored in the encrypted enclave is only decrypted within the CPU -- and even then, it is only decrypted at the request of instructions executed from within the enclave itself. As a result, even someone with root (system administrator) access to the running system can't usefully read or alter SGX-protected enclaves. This is intended to allow confidential, high-stakes data processing to be safely possible on shared systems -- such as cloud VM hosts. Enabling this kind of workload to move out of locally owned-and-operated data centers and into massive-scale public clouds allows for less expensive operation as well as potentially better uptime, scalability, and even lower power consumption. Intel's SGX has several problems. The first and most obvious is that it is proprietary and vendor-specific -- if you design an application to utilize SGX to protect its memory, that application will only run on Intel processors... Finally, there are potentially severe performance impacts to utilization of SGX. IBM's Danny Harnik tested SGX performance fairly extensively in 2017, and he found that many common workloads could easily see a throughput decrease of 20 to 50 percent when executed inside SGX enclaves. Harnik's testing wasn't 100 percent perfect, as he himself made clear -- in particular, in some cases his compiler seemed to produce less-optimized code with SGX than it had without. Even if one decides to handwave those cases as "probably fixable," they serve to highlight an earlier complaint -- the need to carefully develop applications specifically for SGX use cases, not merely flip a hypothetical "yes, encrypt this please" switch.... After discussing real-world use of SGX, Rao moved on to future Intel technologies -- specifically, full-memory encryption. Intel refers to its version of full-memory encryption as TME (Total Memory Encryption) or MKTME (Multi-Key Total Memory Encryption). Unfortunately, those features are vaporware for the moment. Although Intel submitted an enormous Linux kernel patchset last May for enabling those features, there are still no real-world processors that offer them... This is probably a difficult time to give exciting presentations on Intel's security roadmap. Speculative prediction vulnerabilities have hurt Intel's processors considerably more than their competitors', and the company has been beaten significantly to market by faster, easier-to-use hardware memory encryption technologies as well. Rao and Woodgate put a brave face on things by talking up how SGX has been and is being used in Azure. But it seems apparent that the systemwide approach to memory encryption already implemented in AMD's Epyc CPUs -- and even in some of their desktop line -- will have a far greater lasting impact. Intel's slides about their own upcoming full memory encryption are labeled "innovations," but they look a lot more like catching up to their already-established competition.
Published on March 01, 2020 at 12:04AM
"Intel's security plans sound a lot like 'we're going to catch up to AMD,'" argues FOSS advocate and "mercenary sysadmin" Jim Salter at Ars Technica, citing a "present-and-future" presentation by Anil Rao and Scott Woodgate at Intel's Security Day that promised a future with Full Memory Encryption but began with Intel SGX (launched with the Skylake microarchitecture in 2015). Salter describes SGX as "one of the first hardware encryption technologies designed to protect areas of memory from unauthorized users, up to and including the system administrators themselves." SGX is a set of x86_64 CPU instructions which allows a process to create an "enclave" within memory which is hardware encrypted. Data stored in the encrypted enclave is only decrypted within the CPU -- and even then, it is only decrypted at the request of instructions executed from within the enclave itself. As a result, even someone with root (system administrator) access to the running system can't usefully read or alter SGX-protected enclaves. This is intended to allow confidential, high-stakes data processing to be safely possible on shared systems -- such as cloud VM hosts. Enabling this kind of workload to move out of locally owned-and-operated data centers and into massive-scale public clouds allows for less expensive operation as well as potentially better uptime, scalability, and even lower power consumption. Intel's SGX has several problems. The first and most obvious is that it is proprietary and vendor-specific -- if you design an application to utilize SGX to protect its memory, that application will only run on Intel processors... Finally, there are potentially severe performance impacts to utilization of SGX. IBM's Danny Harnik tested SGX performance fairly extensively in 2017, and he found that many common workloads could easily see a throughput decrease of 20 to 50 percent when executed inside SGX enclaves. Harnik's testing wasn't 100 percent perfect, as he himself made clear -- in particular, in some cases his compiler seemed to produce less-optimized code with SGX than it had without. Even if one decides to handwave those cases as "probably fixable," they serve to highlight an earlier complaint -- the need to carefully develop applications specifically for SGX use cases, not merely flip a hypothetical "yes, encrypt this please" switch.... After discussing real-world use of SGX, Rao moved on to future Intel technologies -- specifically, full-memory encryption. Intel refers to its version of full-memory encryption as TME (Total Memory Encryption) or MKTME (Multi-Key Total Memory Encryption). Unfortunately, those features are vaporware for the moment. Although Intel submitted an enormous Linux kernel patchset last May for enabling those features, there are still no real-world processors that offer them... This is probably a difficult time to give exciting presentations on Intel's security roadmap. Speculative prediction vulnerabilities have hurt Intel's processors considerably more than their competitors', and the company has been beaten significantly to market by faster, easier-to-use hardware memory encryption technologies as well. Rao and Woodgate put a brave face on things by talking up how SGX has been and is being used in Azure. But it seems apparent that the systemwide approach to memory encryption already implemented in AMD's Epyc CPUs -- and even in some of their desktop line -- will have a far greater lasting impact. Intel's slides about their own upcoming full memory encryption are labeled "innovations," but they look a lot more like catching up to their already-established competition.
Read more of this story at Slashdot.
Comments
Post a Comment