AMD's Future in Servers: New 7000-Series CPUs Launched and EPYC Analysis
by Ian Cutress on June 20, 2017 4:00 PM EST- Posted in
- CPUs
- AMD
- Enterprise CPUs
- EPYC
- Whitehaven
- 1P
- 2P
With recent fears about security, and given that these processors are aiming to go to the Enterprise space, AMD had to dedicate some time to explaining how secure the new platform is. AMD has had its Secure Processor in several CPUs at this point: a 32-bit ARM Cortex-A5 acting as a microcontroller that runs a secure OS/kernel with secure off-chip storage for firmware and data – this helps provide cryptographic functionality for secure key generation and key management. This starts with hardware validated boot (TPM), but includes Secure Memory Encryption and Secure Encrypted Virtualization.
Encryption starts at the DRAM level, with an AES-128 engine directly attached to the MMU. This is designed to protect against physical memory attacks, with each VM and Hypervisor able to generate a separate key for their environment. The OS or Hypervisor can choose which pages to encrypt via page tables, and the DMA engines can provide support for external devices such as network storage and graphics cards to access encrypted pages.
Because each VM or container can obtain its own encryption key, this isolates them from each other, protecting against cross-contamination. It also allows unencrypted VMs to run alongside encrypted ones, removing the all-or-nothing scenario. The keys are transparent to the VMs themselves, managed by the protected hypervisor. It all integrates with existing AMD-V technology.
Alongside this are direct RAS features in the core, with the L1 data cache using SEC-DED ECC and L2/L3 caches using DEC-TED ECC. The DRAM support involves x4 DRAM device failure correction with addr/cmd parity and write CRC with replay. Data poisoning is handled with reporting and a machine check recovery mode. The Infinity Fabric between dies and between sockets is also link-packet CRC backed with retry.
One element that was not discussed is live VM migration across encrypted environments. We fully suspect that an AMD-to-AMD live migration be feasible, although an AMD-to-Intel or Intel-to-AMD will have issues, given that each microarchitecture has unique implementations of certain commands.
Facebook
Twitter
RSS
131 Comments
View All Comments
davegraham - Tuesday, June 20, 2017 - link
I'm waiting to see consumer sites benchmark a server CPU against retail CPUs and then crow about clocks, etc. ;) it'll be done, it'll be vicious, and people will take it as the gospel truth. heck, let's just get the Cinebench testing done ASAP and call it day ;)Gothmoth - Tuesday, June 20, 2017 - link
yeah why is anandtech reporting about server hardware. nobody is interested in that.just let us take AMDs numbers as gospel.... a interpolate threadripper numbers until august.
SkiBum1207 - Tuesday, June 20, 2017 - link
Excuse me? There are us who use servers to make money - we definitely care about Anandtech's analysis of enterprise hardware.davegraham - Tuesday, June 20, 2017 - link
I am interested in Ian's take but I test this hardware on my own using the toolsets available to me. While I appreciate Johan's insights, I find most of the consumer sites (as Anandtech is one of them) to be reaching when they try to provide realistic workload testing. StorageReview.com does a decent job (mostly), but I'm finding that most reviews, sadly, are hit and miss against test benches and their applicability is...dubious at best.and like LurkingSince97 infers, spec-int is a fanboy benchmark ;)
D
at80eighty - Tuesday, June 20, 2017 - link
did you discover the site yesterday?davegraham - Tuesday, June 20, 2017 - link
lol. who, me? nope. ;)at80eighty - Wednesday, June 21, 2017 - link
sorry, the comment threading is not helpful - i directed that question to Gothmoth's absurd postdeltaFx2 - Wednesday, June 21, 2017 - link
Plenty of people are interested in it, and those people do their own benchmarking. They don't visit Anandtech or Tom's hardware to get this information.LurkingSince97 - Tuesday, June 20, 2017 - link
Except that nobody runs spec-int on their servers.AMD made two mistakes:
1. spec-int should not be used to compare servers across architectures. Instead, run real software that people use on servers. Virtualization benchmarks, JVM stuff, databases, whatever. Real world things.
2. Trying to modify spec-int results (I guess, by using GCC instead of intel's compiler, and compensating for the stuff their compiler does). Yeah, a lot of the tricks that some compilers use on spec-int are absolutely garbage and would not make real-world applications faster -- just spec-int. But there is no objective way to disentangle that. So stay away from it.
IanHagen - Tuesday, June 20, 2017 - link
Intel's compiler cripples code on AMD and VIA chipsAnti-competitive at the machine code level
https://www.theinquirer.net/inquirer/news/1567108/...
Intel finally agrees to pay $15 to Pentium 4 owners over AMD Athlon benchmarking shenanigans
https://www.extremetech.com/computing/193480-intel...
FTC Settles Charges of Anticompetitive Conduct Against Intel
https://www.ftc.gov/news-events/press-releases/201...