Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
AMD Businesses Encryption Privacy Security Hardware

AMD Ryzen Pro 3000 Series Desktop CPUs Will Offer Full RAM Encryption (arstechnica.com) 53

An anonymous reader quotes a report from Ars Technica: Monday, AMD announced Ryzen Pro 3000 desktop CPUs would be available in Q4 2019. This of course raises the question, "What's a Ryzen Pro?" The business answer: Ryzen Pro 3000 is a line of CPUs specifically intended to power business-class desktop machines. The Pro line ranges from the humble dual-core Athlon Pro 300GE all the way through to Ryzen 9 Pro 3900, a 12-core/24-thread monster. The new parts will not be available for end-user retail purchase and are only available to OEMs seeking to build systems around them.

From a more technical perspective, the answer is that the Ryzen Pro line includes AMD Memory Guard, a transparent system memory encryption feature that appears to be equivalent to the AMD SME (Secure Memory Encryption) in Epyc server CPUs. Although AMD's own press materials don't directly relate the two technologies, their description of Memory Guard -- "a transparent memory encryption (OS and application independent DRAM encryption) providing a cryptographic AES encryption of system memory" -- matches Epyc's SME exactly. AMD Memory Guard is not, unfortunately, available in standard Ryzen 3000 desktop CPUs. If you want to build your own Ryzen PC with full memory encryption from scratch, you're out of luck for now.

This discussion has been archived. No new comments can be posted.

AMD Ryzen Pro 3000 Series Desktop CPUs Will Offer Full RAM Encryption

Comments Filter:
  • and just what does it really buy you in increased security ? Is there even any way to quantify this ?

    • and just what does it really buy you in increased security

      Defense against specter and meltdown?

      • Re: (Score:3, Informative)

        by Anonymous Coward

        It's better, but not good enough. We need host-proof computing using fully homomorphic encryption.

        Among others, IBM has been working on actual silicon.

        • by Khyber ( 864651 )

          It will never be good enough. Man can make it, man can break it. It's just that simple.

      • by Guspaz ( 556486 )

        Does it, though? My understanding is that both Spectre and Meltdown involve grabbing data from the CPU cache due to speculative execution, which would have required the CPU to decrypt the memory to get it in the cache in the first place.

        • Does it, though? My understanding is that both Spectre and Meltdown involve grabbing data from the CPU cache due to speculative execution, which would have required the CPU to decrypt the memory to get it in the cache in the first place.

          They get memory "location" from cache. If the memory location points to encrypted data then what do you get?

      • Defense against AMD's Secure Platform Processor (PSP) (their equivalent of Intel Management Engine) would be nice.

        https://www.extremetech.com/co... [extremetech.com]

        AMD's PSP is its equivalent of the Intel Management Engine and has been criticized for many of the same issues as that solution. Security researchers have been publicly unhappy with AMD and Intel's decision to keep details of how these chips operate under wraps because they function in secret, entirely divorced from the operation of the primary CPU or operating system.

        • by AmiMoJo ( 196126 )

          One key difference with the AMD PSP in desktop parts is that it doesn't support remote management. With Intel's IME you can not only wake the computer remotely, you can use VNC to view it's screen, enter the BIOS, boot to the OS etc. AMD does not support that on desktop so the main way in which Intel IME is exploited has been removed.

          It's still not great, they should open source it, but also you do need something to provide verification for secure boot. Yes, some people say secure boot is evil, but actually

      • and just what does it really buy you in increased security

        Defense against specter and meltdown?

        No. It really doesn't get you anything. PR for AMD, I guess, but that doesn't help users.

      • Defense against specter and meltdown?

        What does Harvey have to do with this, or his Spectre?

      • Defense against specter and meltdown?

        Maybe. That depends upon when does decryption occur - before it enters the CPU cache, or after.

      • Re: (Score:2, Informative)

        by drinkypoo ( 153816 )

        Defense against specter and meltdown?

        AMD processors are already invulnerable to MELTDOWN, since they check to see if you have access to a memory location before accessing it, but yes it will help with SPECTRE.

    • Re: (Score:3, Interesting)

      by bblb ( 5508872 )

      It'd protect against ram scraping, which could harvest everything from web logins to to credit card numbers or encryption keys for other applications... anything that's stored in the clear within RAM. As for performance hit, in most situations I don't expect it would be too dramatic with modern systems having sufficient cores and bandwidth available to deal with the cryptography without bogging down too much unless they're working under a heavy load in which case it could be significant but would likely be

    • by tlhIngan ( 30335 ) <[ten.frow] [ta] [todhsals]> on Wednesday October 02, 2019 @05:57PM (#59263196)

      and just what does it really buy you in increased security ? Is there even any way to quantify this ?

      These days, practically no performance hit since the decryption and encryption setup is done while the RAM latency is happening so when the data arrives, the computed keystream can be XOR'd with the incoming data to encrypt/decrypt iut.

      The benefits are many. First, the system will always boot fresh - data from the previous boot is lost because when the memory controller is initialized, it makes a new key, so you can't recover data after a reset. So any private or secure data is wiped. Things like encryption keys and such that were stored in RAM end up wiped. You can accomplish this right now by having RAM zeroed on boot, but on modern systems this can take a long while, whereas memory encryption makes it instantaneous. It's like why an SSD can be securely erased in seconds while a hard disk takes hours - the SSD discards the old key and regenerates a new key, leading to the old data being completely inaccessible. The hard disk must individually write to every sector on the platters.

      Second, if you spy on the memory bus, you can't find out what's there. Nor can you use it to patch RAM contents. Note that memory encryption generally encompasses both address scrambling and data scrambling, so even sequential accesses to memory end up being randomized (You might think this is a problem, but it generally isn't since RAM doesn't get accessed a byte at a time nowadays - you generally get at it a row at a time and the bytes are scrambled per row

      The real problem is the key generation. Typically chips with memory encryption units need a hardware RNG - the RNG supplies the key programmed into the memory controller. So your encryption strength is only as strong as the RNG.

      • It's like why an SSD can be securely erased in seconds while a hard disk takes hours - the SSD discards the old key and regenerates a new key, leading to the old data being completely inaccessible. The hard disk must individually write to every sector on the platters.

        Both SSDs and HDDs can have hardware encryption. The encryption is done by the controller, so there's no dependency on the specific block access mechanism or media.

        Taking hours to erase an HDD involves repeated writes to each block, but there are known methods of attacking such erasing because HDDs write stochastically to the magnetic domains for each bit due to non-deterministic head positioning. So, software or hardware encryption are the best ways of erasing ... aside from real hot furnaces to melt the

        • ... aside from real hot furnaces to melt the entire drive.

          Pretty much.

          You melt the drive down, make ingots, then travel around the world burying a single ingot in each country you visit. When the ingots are gone. You are 99.99% safe.

        • by Khyber ( 864651 )

          "Both SSDs and HDDs can have hardware encryption."

          Turns out those drives are pretty much useless as their encryption isn't ever enabled or is utter shit.

        • by tlhIngan ( 30335 )

          Taking hours to erase an HDD involves repeated writes to each block, but there are known methods of attacking such erasing because HDDs write stochastically to the magnetic domains for each bit due to non-deterministic head positioning

          Even a 1 pass HDD erase takes a long time - media speeds are only on the order of 200MB/sec, so 5 seconds to erase 1GB, 5000 seconds to erase 1TB, which is just under an hour and a half for a 1TB drive.

          Though there are reports that 1 pass is more than sufficient - the small si

      • If all they do is XOR a keystream against the memory contents, bus snooping can directly see each individual bit change in memory, though they may not know whether the direction of the bit change was 1->0 or 0->1. Even if the contents is encrypted/decrypted with an address-dependent key in AES, bus snooping can still see whether the contents of a memory block changed. These measures may provide some security, but the random-access nature of memory reads and writes makes only ECB usable as key handlin

    • Probably nothing significant. The CPU simply pipes it through whatever crypto hardware block it has. Maybe a very slight latency hit.

  • I'm intrigued by how many clock cycles AES will add to, say, a rotate bits right opcode.

  • Comment removed based on user account deletion
    • Why not both?

    • Re:ECC? (Score:4, Informative)

      by Afell001 ( 961697 ) on Wednesday October 02, 2019 @06:00PM (#59263210)
      ECC Ram is supported by the Ryzen processor. The question lies in your motherboard supporting it. The good news is that most motherboard manufacturers do support unbuffered ECC. I've set up Ryzen Threadripper workstations with ECC memory. It was expensive, but worth it for the peace-of-mind.
      • > I've set up Ryzen Threadripper workstations with ECC memory. It was expensive, but worth it for the peace-of-mind.

        You wouldn't happen to have a cost/GB comparing ECC to non-ECC by chance?

        Any details you can share on what "was expensive" means please? How many GB did you end going with? 16? 32? 64?

        I'm looking to upgrade from an i7 to Threadripper next year and still trying to decide if ECC is worth it for hobby multithreaded number crunching (probably going to run some flavor of Linux.)

        TIA!

      • Note that the Ryzen CPU families support ECC memory, but the motherboard mentioning support is not enough.

        I got bitten by this myself, Gigabyte actually changed the wording (after I purchased mine) on several motherboards that they support ECC memory, but they don't use the checksums. So I paid about +50 percent more for lightly slower memory compared to non-ECC modules. I tried all kinds of tests before some comment pointed out the new wording, including memtest64 and various Linux tools and ways to check

      • by Agripa ( 139780 )

        Except for some early ones, all Ryzen CPUs support ECC but in this case, the APUs also apparently support ECC making them unique.

    • No more than 256 bits wouls be affected. Probably only that one bit.

      The *most secure* mode to do encryption has the property that each bit of ciphertext depends on all preceding bits of plaintext and vice-versa. However, that would mean that in order to read the last bite of memory, one has to process every byte. That would be rather bad for performance. :)

      Enter block ciphers. With block ciphers like AES, each 128-256 bit block is encrypted and decrypted separately. Preferably not with the exact same key

    • by Agripa ( 139780 )

      Uhh, it better have ECC. It's one thing to have a bit-flip that crashes a program, or worse hits the kernel and causes a panic (reboot). But what happens when the entire stack in RAM is encrypted. Wouldn't a bit-flip cause the rest of the addressable space to be non-accessible if it fails to decrypt on read?

      Most Ryzen CPUs support ECC including these however in this case, the APUs also support ECC making them unique.

  • by Opportunist ( 166417 ) on Wednesday October 02, 2019 @05:54PM (#59263180)

    You think this will protect your data from prying eyes? It's more likely that this will protect the software from you.

    • by Ceseuron ( 944486 ) on Wednesday October 02, 2019 @06:14PM (#59263262)

      I'm certainly not getting my hopes up. This is old news and has already been reported on. Intel is doing something similar. The concept appears promising at face value, but a couple of noteworthy papers have already been produced on this topic:

      When Encryption is not Enough: Memory Encryption is Broken - https://www.ssrc.ucsc.edu/Pape... [ucsc.edu]
      SEVered: Subverting AMD’s Virtual Machine Encryption - https://arxiv.org/pdf/1805.096... [arxiv.org]

      From the look of it, the proposed solutions by both AMD and Intel don't appear to do much to protect against Specter/Meltdown or Ryzenfall vulnerabilities. I'd be curious to find out what the performance hit would be with something like this in comparison to any benefits it provides.

    • It's more likely that this will protect the software from you.

      I think the most likely thing is that you have no idea what you are talking about, since this a hardware only encryption layer and any software requesting memory contents gets it encrypted, including your vicious attack on some poor software.

    • by AmiMoJo ( 196126 )

      Encrypted RAM protects you in a number of ways.

      - Cold boot and warm boot attacks don't work. The key is automatically regenerated at boot.

      - DMA attacks over Thunderbolt don't work. DMA attacks from malware-infected peripherals (e.g. GPUs) don't work.

      - VMs can be properly isolated from each other, so even if they are exploited the data they extract from other VMs or the host is encrypted.

      - Encryption keys such as the one used for your software encrypted HDD are protected. The kernel can use a different key f

      • How does it affect things like debuggers?

        • by AmiMoJo ( 196126 )

          If the debugger is running in the same OS as the task it is debugging then it sees everything decrypted. This doesn't provide inter-task memory protection, only between different VMs on a hypervisor and for the kernel.

      • by tlhIngan ( 30335 )

        - DMA attacks over Thunderbolt don't work. DMA attacks from malware-infected peripherals (e.g. GPUs) don't work.

        Incorrect. These do work since the encryption is done at the memory controller level. And they have to, since DMA is the only way to get the speed you need.

        Basically both these devices access system memory through PCIe memory mapper unit, so they can have access to unencrypted RAM contents (the data flow is from [Thunderbolt-]PCIe-Memory controller (+MEU)-Memory

  • Is this specifically a mitigation against microarchitectural attacks? Clearly, the CPU must decrypt the RAM for software to use what's stored there, and so it doesn't seem as though RAM encryption would be any mitigation against software- or kernel-based memory-scouring exploits.
    • by AHuxley ( 892839 )
      Malware that goes looking over different parts of memory.
      People who try something like a Cold boot attack eg https://en.wikipedia.org/wiki/... [wikipedia.org]
      RAM encryption will help will all that right?
      • by Chromal ( 56550 )
        I guess what I'm asking is: why wouldn't the CPU memory controller obligingly decrypt the memory for the malware? How would it even distinguish?
        • by AHuxley ( 892839 )
          Ask the CPU maker when they will add that support for the different types of CPU they sell?
    • Preperation to lock down reverse engineering from ram scrapes. Also note the move to reduce root access to accessing kernel level functionality and was it AMD or ATI with that shady licensing worded to block any unpermitted access to the encrpyted video? This is all starting to reek of a strategic scheme.
  • Is this so that if someone breaks into your datacentre/living room and steals your DRAM they will not be able to make sense of what is stored there?

    Sounds to me like a "solution" in search of a "problem" ...

    • Is this so that if someone breaks into your datacentre/living room ...>

      Who keeps their PC in the "living room" honestly.

      I'm in the "study" atm /poll

  • This is pretty much old news, nothing new for AMD Pro processors. It is a neat feature, but not as ground breaking as this article insinuates. This is really just a new line to get the Pro in line with 3000 processors.

Always draw your curves, then plot your reading.

Working...