AMD’s Zen core has been revealed in detail but with Epyc the company added a few juicy details. SemiAccurate is particularly interested in the security aspects on the new CPU line which is what we will discuss here.
Epyc has a bunch of new instructions, full crypto hardware, and new platform options that are going to do quite well in the enterprise and cloud spaces. These markets are increasingly concerned with security and after the woeful showing by Intel around security coupled with their continued bungling of messaging and implementation on the subject, AMD has a golden opportunity. (Note: SemiAccurate feels Intel’s security architecture is correct, everything else is abjectly broken) Lets take a look at what AMD has to offer.
The first one is a big bang, SME and SEV. These stand for Secure Memory Encryption and Secure Encrypted Virtualization, and they both do what their names imply. These functions are based on a hardware security processor, a 128b AES engine attached to the memory controller. There is also the PSP, Platform Security Processor, a completely different device specifically an ARM Cortex-A5 SemiAccurate exclusively told you about years ago. It has been there for a while but only now are they admitting that it is there with the Epyc launch. We have the handy picture below showing where it resides, obviously not to scale.
Look here for all your PSP needs
The PSP controls boot, system security, and runs its own OS/RTOS that keeps the system functioning. It also provides secure boot and has full TPM functionality as well, something pretty much required for any modern system in a corporate environment. Like Intel, AMD also allows for an external TPM to be used instead of the internal functions if an OEM or customer requires it. This isn’t academic, many organizations require a specific TPM and some even have their own bespoke parts. Think TLAs and governments here, a large, lucrative, and at times very picky customer base. One thing SemiAccurate is unclear on is whether the SEM and SEV keys are stored here or elsewhere, in the crypto processor itself for example.
SME could be the killer app for AMD. SemiAccurate had extensive conversations with the AMD engineers involved in SME and SEV. At least to our knowledge level, AMD did the right thing for the right reasons. Until deep third-party analyses come out what we can say is things look really good. What SME does do is what the name implies, encrypts memory on the fly.
This may not sound important because what can you do with memory in a running system? There are two answers to this, the first is quite simple, NVDIMMS. The second is made very real by Intel’s AMT debacle, with full DMA access to a system you can read memory arbitrarily. Granted AMD does not have the remote security woes of Intel but they may in the future, so an attacker should in theory only be able to read non-encrypted pages. We are still a bit unclear if a DMA request can cause an encrypted page to be decrypted without explicit permission from the page’s owner. The information we have seems to say SME protects against DMA/RDMA snooping though.
SemiAccurate asked AMD about the performance hit for SME and they replied that it has a 7-8ns latency hit and a <3% overall performance drop for completely encrypted memory. It may seem obvious but the performance penalty is workload dependent, mainly on how hard your application hits memory. Luckily for users this drop is completely optional, use it if you want, ignore if you want, but the option is there. There is one key for the system and you can choose which pages are encrypted and which are not. It is very flexible.
The part that makes SME a killer app is that it is both hardware based and transparent to the user and software. In theory you could set it up once per server, take a minimal performance hit from the encryption, and call it done. Hypervisor vendors and OSes will likely build SME in to their offerings in short order and that is about all you need. From this point SME usage will be granular and performance drops will be both minimal and only where required. More importantly even if you have no software that supports SME, you can simply turn it on in the BIOS for everything and get the full benefit. And the maximum performance penalty, slight though it is.
If you need security SME is a no-brainer, it will work from day one with a BIOS toggle and only get better as software support increases. Even if nothing ever supports it officially, Microsoft and VMWare look to be on board, it will be of direct benefit to the customer out of the box. Intel has SGX but, well, they won’t talk about it, what it does, how it does things, the performance hit, or anything you need to base a decision on. As SemiAccurate previously reported, SGX is pretty broken in “early Purley” but we can’t say if it will make the cut on mid-life Purley or the 2018 Purley refresh/Cascade Creek. One thing we can say is that SGX is not hardware in the same way as SME, it takes recoding and recompiling to enable any benefit at all. On paper AMD’s SME the vastly superior way of doing things.
SEV in action or not
Similar but more complex is SEV, it also encrypts VM’s but does it in a more granular fashion with an aim of keeping VMs on a system from snooping on each other. There is a key for the OS/VMM and one per VM or similar grouping of functionality. As with SME you don’t have to use it and the performance hit was unspecified but it is likely to be the same as SME. AMD took pains to point out that the keys are handled in such a way that a cloud provider does not have access to the keys for a VM and similarly the VMs do not have access to the VMM/OS keys.
AMD gave us a little more detail on how keys are implemented in SEV and again from the depths we were able to go, it looks like they did right here too. When you bring up a VM on an Epyc machine, it checksums the VM and attests the use owner what it found in an encrypted and signed manner using the platform keys. If the VM is considered correct by its owner, it can then provision SEV keys to the VM while being protected by temporary keys generated by the VM itself and unknown to the VMM/OS/cloud provider. This seems quite similar to how things are done now with the additional layer of secure key storage in hardware plus the crypto engine.
Moving or live migrating secure VMs between platforms is handled in a similar fashion. A secure tunnel is generated between the two boxes in the traditional way. Once established the VM is decrypted using the platform keys, re-encrypted (Think SSL) for transmission, and once over the wire, encrypted using a SEV key for the new box. This methodology is the same as VM migration without SEV, it is just that SEV allows for hardware key storage which significantly lessens the attack surface.
For both SEV and SME AMD looks to have done the right thing by putting the mechanisms in hardware and making it all as transparent to the software and end-user as possible. For initial deployment the barriers to entry are minimal, a single BIOS setting, but there is some performance hit. Intel’s SGX requires significant code changes and is not software transparent at all, plus any research into it requires onerous NDAs that essentially preclude disclosure of any flaws found. Those that need security will research both methodologies in detail but from the public point of view, one path is clearly superior.
All of this is nice but the crypto engine, SME, and SEV are part of the uncore, what about the core itself? That part hasn’t been neglected either and the security front starts out with dual AES pipes for high throughput. Think AES-NI with, again on paper, no real bottlenecks. On top of this there are nine new (mostly) security related instructions.
Epyc’s new instructions
The top seven are basically catching up to Intel, the last two are the interesting ones. CLZERO does what it sounds like and clears a cache line. For those not into low-level features this instruction can mitigate some cache line poisoning attacks. The PTE Coalescing instruction will combine small contiguous page tables into a single large table saving multiple TLB entries. It may not be directly security related but it is useful.
Last up on the security front is the PSP itself, something that has been the topic of much consternation of late due to Intel’s AMT missteps. Like Intel’s ME (the hardware AMT is based on), AMD’s PSP is not open source. Many groups are calling on AMD to open the PSP source code, something SemiAccurate feels strongly about, and we think there is progress happening on that front but don’t expect it really soon. Opening up security related code is a mandatory minimum for any platform to be considered secure. Intel’s AMT hole was a direct result of them not doing the right thing on security and there are many more similar holes lurking in the dark. Yes this scares us more than you think.
This fear is why SemiAccurate questioned AMD about the details surrounding SME, SVE, and the PSP. On the PSP front we were similarly impressed with the answers we got. First and foremost is the simple fact that the PSP firmware must be correctly signed to run. Having the hardware that controls the root of all your platform security running only signed code seems like an obvious, basic, bare minimum requirement for any security related technology. It also seems like something even a 3rd grader would flag as mandatory, but how can we say this politely, INTEL DOES NOT DO THIS. No joke. Now do you see why we are scared?
Getting back to the details, AMD seems to have done right with the PSP on several levels. You can have a key hierarchy for PSP firmware/code signing, something we expected and were explicitly told was doable. For really security conscious organizations, again think governments and TLAs, the ability to replace the platform keys with non-AMD versions is technically possible. Doing this requires both a huge degree of technical skill, lots of manpower, and significant expense, but if you need it, you need it, and it is there. One thing SemiAccurate didn’t confirm is key revocation, but considering we didn’t dig up any major missteps with security on Epyc, we assume that capability is there too.
So all in all Epyc is unlike any AMD platform of the past on the security front. AMD didn’t just follow Intel’s footsteps in security, they went far beyond anything Intel has done. AMD’s SME and SEV are going to be a great advance out of the box and will only get better as software support increases. A one button transparent memory encryption feature is a killer app, why wouldn’t you turn it on? The core changes catch up to Intel’s latest chips and go a bit beyond in a few areas. Best of all the company didn’t seem to screw anything obvious up. Given the current climate of security, hacking, and related problems, security is a key decision point for sales and AMD has something unique and useful that Intel can’t match for generations.S|A
Latest posts by Charlie Demerjian (see all)
- HyperX ships it’s 60 millionth enthusiast memory module - Oct 15, 2018
- Bittware/Nallatech water cools 300W of Xilinx FPGA - Oct 12, 2018
- More on Intel’s 10nm process problems - Sep 17, 2018
- Intel puts out another 14nm 2020 server platform - Sep 11, 2018
- Why Can’t Intel Supply Enough 14nm Xeons? - Sep 10, 2018