Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Intel Hardware

Chasing AMD, Intel Promises Full Memory Encryption in Upcoming CPUs (arstechnica.com) 53

Posted by EditorDavid from the in-the-chips dept.
"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.
This discussion has been archived. No new comments can be posted.

Chasing AMD, Intel Promises Full Memory Encryption in Upcoming CPUs More

Chasing AMD, Intel Promises Full Memory Encryption in Upcoming CPUs

Comments Filter:

  • Keys (Score:5, Informative)

    by Anonymous Coward on Saturday February 29, 2020 @01:42PM (#59782258)

    Remember, if you as the owner aren't allowed to know the keys... then it's not about security.

    In the late nineties Microsoft/Intel etc collected together and decided that the next frontier in computer security was locking out the owner.

    Only they would be in control.

    Think of you PC and jail - you can put evil people (applications) in cells and control them.

    The problem with big tech's vision of this... you aren't are the prison warden. You're just another inmate.

    They are the warden.

    And they've been working towards this ever since. And yes... it is DRM.

    • Re:Keys (Score:5, Insightful)

      by GameboyRMH ( 1153867 ) <gameboyrmh@@@gmail...com> on Saturday February 29, 2020 @02:11PM (#59782342) Journal

      Came here to say this. "Locking out the sysadmin" = DRM. Anything approaching working DRM would be the worst invention in the history of computing, and TPTB are pushing so hard for this technology that the first company to achieve it would instantly have a massive advantage, and any competitors would be forced to catch up quickly or die. It's a terrible race to the bottom that we can only hope takes as long as possible.

      • Came here to say this. "Locking out the sysadmin" = DRM. Anything approaching working DRM would be the worst invention in the history of computing, and TPTB are pushing so hard for this technology that the first company to achieve it would instantly have a massive advantage, and any competitors would be forced to catch up quickly or die. It's a terrible race to the bottom that we can only hope takes as long as possible.

        I would say locking out the user from his own memory = DRM, that is what Intel SGX does. The full memory encryption, protects individual VMs from the host, so it a sort of paranoid thing you can use to add a bit more protection to a hosted enviroment. It has no use for normal end users.

      • Anything approaching working DRM would be the worst invention in the history of computing

        Yes and no. Yes, personal liberty is important. No, I remember a time where you weren't even able to apply security updates to a computer fast enough to prevent it from being owned because of the amount of "liberty" people exercised by purposefully ignoring windows updates.

        Users in general have proven they are not to be trusted with their computers, that goes for corporate networks (where lockdown is the norm) to the home unwashed masses who don't understand that the box their screen is attached to is not c

        • We've solved the lack of windows updates with automatic updates, no DRM necessary. With DRM your computer can arrive owned out of the box without even giving you a chance to avoid it with quick/airgapped updates.

          Also I've found consistently that people who don't know about computers call their computer the "CPU," I think it might come from early mainframe computers where the CPU could've actually been a separate unit.

      • ... i must be missing something here , who exactly has access and what code would be in it if no one has access to it but most of all ... a part of the pc where the sys-admin can't reach , what could go wrong, lol , i seriously don't get who gets to write code to it ... if it's the OS then its a matter of whacking the OS ... this must be above my braingrade

    • Re: (Score:2)

      by hey! ( 33014 )

      What if *nobody* had the keys? What then? If I didn't know better I'd think you're commenting on the technology without actually finding out what it does.

      The problems with this technology is that it doesn't privilege *anybody*. There's a lot of good things about that, but there are problems too, like how do you detect malware?

      • Re: (Score:2)

        by ezdiy ( 2717051 )

        What if *nobody* had the keys? What then?

        Those are the actual legit techniques, primarily to assure privacy and integrity of software on untrusted hardware. That's the whole field of ZK-computing, PIR algorithms. In spite of their security soundness, there are practical roadblocks:

        1) They're extremely expensive moon math crypto, as opposed to el cheapo symmetric AES. Symmetric DRM is also much easier to understand/implement.
        2) Jails as a whole are far easier to mass-market than legitimate ZK solutions

    • "In the late nineties Microsoft/Intel etc collected together and decided that the next frontier in computer security was locking out the owner.

      "Only they would be in control."

      I posted this comment last year: Intel management seems insufficient. [slashdot.org]

      And I posted this comment 13 1/2 years ago: Ways to improve Intel's management. [slashdot.org]

      Some of my ideas:

      1) Intel's became Zombie-like.

      2) To get the part numbers necessary to place an order, it was necessary to jump through hoops...

      3) Top managers should

    • They also made the keys available to whomever they wished to grant access to. So-called "Trusted Computing" is based on a chain of keys, including revocation keys and keys authorized to supplant other keys, which keeps the master keys _and_ the individual CPU's private keys in Microsoft managed escrow. The system is designed both to allow vendor or government recovery of all data at whim, but to supplant the CPU's or any new keys at whim of the master key owners and other keys along the chain. The work was

    • This sounds like a great way to implement a permanent, invisible, and un-addressable rootkit. I wonder if this isn't something that was suggested by a certain 3 letter agency. /tinfoil

    • Re: (Score:1)

      by AHuxley ( 892839 )
      If the NSA and GCHQ are cool with the product design ... then its "encrypting" as expected :)

    • Re: (Score:2)

      by AmiMoJo ( 196126 )

      No, not having access to the keys is the best option for you. It has two advantages:

      1. The keys cannot be stolen. If there is simply no way to access them then malware can't take them.

      2. The law can't force you to hand them over.

      The way to manage malware like DRM is to not run it on your computer.

    • Re: (Score:3)

      by tlhIngan ( 30335 )

      Full memory encryption doesn't really have keys though. Because every time you boot your machine, the keys change.

      It's useless otherwise -t he whole point is to ensure that anyone snooping on the memory bus can't get at data in memory.

      After all, it was proven that data in memory can be reliably read minutes after power is lost, so you have access to a powered on machine, you can power it down, remove the memory, and read out the contents before they degraded. (And get at stuff like encryption keys and such

    • In the late nineties Microsoft/Intel etc collected together and decided that the next frontier in computer security was locking out the owner.

      But were they wrong? Look at where we got to. Owners purposefully worked against their own self interest in terms of security practices leading to a world where you couldn't even apply windows updates fast enough to prevent your computer from getting automatically owned when connecting to a network thanks to a massive wide breakout of widely wormable malware.

      Maybe we should approach this like vehicles. Regulate and lock the owners out, and then give them issued permits after they pass an exam proving they a

  • Intel's plan (Score:4, Insightful)

    by Mashiki ( 184564 ) <mashiki@gmail.cBALDWINom minus author> on Saturday February 29, 2020 @01:53PM (#59782296) Homepage

    First guys, we're falling behind AMD in the race. So use whatever shortcuts you can in order to beat them. And no, I don't care it's compromising branch predictability and causing security issues. Speed is all that matters!

    These vulnerabilities! How did this happen? Why didn't anyone warn us that this could cause serious problems, and people are seeing up to 40% losses in performance because of our patches.

    Okay guys, we're so far behind that we're gonna try something radical again! We're not gonna copy AMD, we're gonna make our own encryption that also includes various branch prediction directly to the encrypted data! And make sure there isn't a performance impact with on-chip encryption. And no, I don't care it can cause security issues!

    • So this is what Intel has been working on: More stuff you "own" that you don't actually control.

      Rather than, you know, fixing Meltdown (doing privilege checks and other memory access tasks in the wrong order), and looking for better mitigations for Spectre... (Although granted that actually fully fixing Spectre without a significant performance hit might not be possible. But that doesn't apply to Meltdown.)

    • First guys, we're falling behind AMD in the race. So use whatever shortcuts you can in order to beat them. And no, I don't care it's compromising branch predictability and causing security issues. Speed is all that matters!

      Well two things here:
      1) Intel was ahead at the time they introduced this.
      2) The security issues resulting from their decisions have been the most irrelevant blown out waste of outrage that has ever hit the industry. It is a real shame that AMD didn't adopt the same approach trading off a completely irrelevant security issue for a very relevant increase in speed.

      The average user does not run a datacentre with multiple virtual users on the other end and would be better placed with a faster AMD chip. Likewise

  • should be like old IBM (Score:5, Interesting)

    by jmccue ( 834797 ) on Saturday February 29, 2020 @02:00PM (#59782314) Homepage

    Intel should be forced to treat new product announcements like IBM needs to (or use to need to).

    Due to a law suit in the 60s/70s? IBM was forced not to announce any new products until it was ready. Intel seems to be playing that old game IBM created decades ago

  • There is no purpose in "Encrypting Memory" and it will not and cannot achieve any security purpose at all that cannot be better achieved through other means.

  • Without the memory code injection that I think a lot of them work on, I am never going to see the end of another button masher with a neat story like Assassin's Creed.

  • I don’t get it (Score:3)

    by 93 Escort Wagon ( 326346 ) on Saturday February 29, 2020 @03:21PM (#59782480)

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

    Okay, admittedly this is not an area where I am particularly knowledgeable. But I don’t get why this should be true. Why should you have to “design an application” to get this benefit at all, or to use it efficiently? Shouldn’t all that be transparent to a developer or end user, like it is with hard drive encryption?

    • To sell more Intel CPUs of course.

      Theoretically this could be quite useful for Amazon or Azure to protect customer data. Practical is a different matter as SGX has 3 vulnerabilities and one serious as malware can sign itself and use sgx to hide itself making it impossible to remove.

      Intel has been doing more slimy things recently to fight off AMD. So weird to see them behind AMD?! Thry paid Adobe and Handbrake to use their compilers to use more tricks and broke ieee standards to cripple fpu performance on no

    • Re: (Score:2)

      by AmiMoJo ( 196126 )

      AMD only supports the OS or hypervisor setting which sections of RAM are encrypted. Some RAM can't be encrypted because it's used for DMA with peripherals, and hypervisors use it to isolate VMs from each other.

      Intel allows applications to have small bits of RAM encrypted for their own use, e.g. DRM.

    • The point is to protect user data, it is about the application protecting itself from the OS, or by extension, malware.

      So the application has to know about it and use it.

  • SGX is a security threat itself (Score:5, Interesting)

    by Billly Gates ( 198444 ) on Saturday February 29, 2020 @03:30PM (#59782510) Journal

    Hackers have used to hide rootkits and malware making it impossible to remove or even detect.

    I turned it off in my own i9 at home because of this and the fact my event viewer always complained about it.

    Funny the other comments here talk about DRM this or that. Even though it's not designed for DRM I do agree with the other commenter on taking away system admins access. Imagine ransomware or criminals using this?

  • There's nothing wrong with walled gardens. (Score:3)

    by ezdiy ( 2717051 ) on Saturday February 29, 2020 @04:33PM (#59782650)
    Built-in CPU I/O obfuscation is a cheap and robust way to make one. What is lacking is legislation. Make a clear distinction between general computer hardware, and rented appliances of which you have no ownership, their real owner only lets you use it according to their terms - a lease agreement.

    Chiefly, a string of class action cases need to occur, arguing that you cannot sell property that you don't give up use rights for. All DRM and walled gardens are ultimately just someone "letting" you use it, instead of allowing you to use the product as you see fit. Mandating such hardware to be only rented out would also curb the constant problem of the walled garden "closing down", the scam suddenly rendering all the "purchases" useless, with no compensation. Only after prolonged and loud consumer outcry people might start to realize the distinction between rent/own wrt use rights even exists.

    Worst case, the frog can boil reaal slow, and another scenario is another instance of scam like Copyright, but this time even more nightmarish because it now extends to physical world. Here here, buy this stuff, except you technically don't have use rights to it. I can easily see people simply getting used to that shit.

    • Monopolism is a crime for the same reason as racketeering.
      And walled gardens are localized monopolism.
      I guess there always is a sucker though. In this case: You.

  • This is not exactly a security hole, DRM vehicle, way to restrict users' ownership of a PC, or a walled garden in making... until you actually enable it (it can be disabled at BIOS level, right?) Of course, there will be various applications, games etc. that will complain and insist that they absolutely need SGX and that you must enable it, but we at least should try to resist the temptation. For the computers I own, I can say that I will never enable that (until Intel makes it mandatory. of course). If a g

  • Cue the kids actually falling for it, and calling us "old" for "still" being wary of Intel. Because they don't know that it's decades of bad behavior.

    Sorry. Decades of bad history require decades of good history, to regain trust.

Slashdot Top Deals

No spitting on the Bus! Thank you, The Mgt.

Close