AMD EPYC "CryptoNow!"
Talk about the hardware protection of user information processors AMD EPYC began two years ago. Therefore, it cannot be said that the protection of memory and virtual environments available today in AMD server processors with the Zen architecture came as a complete surprise. On Gikah / Habré, you can read about this in the EPYC announcement , in the ESET NOD32 blog and in the Internet-based David Kaplan presentations from AMD. The architecture of this kind of protection was described in detail by CodeRush in the article “ On UEFI Security ”, for which he was especially grateful. It really was a look into the future.
The ASUS KNPP-D3 server board with dual AMD EPYC 7551 processors in the RS700A-E9-RS4 package supports a set of proprietary encryption technology from Advanced Micro Devices
When the opportunity arose for us to explore the ASUS KNPP-D32 motherboard with two EPYC 7551s, the challenge was to determine the features of crypto protection implemented there. Not least because it is difficult to imagine a different use of such a platform, except in the form of a hostel for virtual machines. All this farm, packed in a 1U rack-mount case with a terabyte of memory of 64 processor cores, is a good illustration of the high proportion of computational capabilities. (When sparing mode of power consumption, by the way).
Protection of user data is seen in AMD as a triple task consisting of memory encryption ( Secure Memory Encryption ), virtual encryption ( Secure Encrypted Virtualization) and processor context encryption (Encrypted State). The second volume of the “ AMD64 Architecture Programmer's Manual ” reports that you can find out if the platform is ready by running the CPUID instruction. Its 8000001Fh function in the EAX, EBX, ECX and EDX registers gives a complete picture of the state of cryptographic protection. Let's use the JavaCrossPlatformCPUID utility.
Although we do not find the desired function among the bookmarks, the result of its work can be seen in the dump - the EAX register contains 0000000Fh. Page 534 of the above document suggests that all security modes on the ASUS RS700A-E9 platform are normal.
However, you can not go into details. AIDA64 reports the same result. True, information about support for the Secure Memory Encryption mode is for some reason not available to users of this program — another argument in favor of direct diagnostics via the CPUID functions.
Now, cloud services are simply obliged to guarantee the residents of the communal apartment that their virtual machines are completely isolated from each other, as well as from the inquiring eye of the host platform. By the way, optimists may not encrypt their guest tasks: along with encrypted virtual peacekeepers, unencrypted virtual machines also coexist (until now, they didn’t have to choose - you had to be “like everyone else”: either or).
Things are going to be easy - to assess the overhead of encryption: regardless of the processor performance, encryption algorithms have always created and continue to create sensitive overheads. The site techpowerup , referring to AMD, claims about an increase in the delay in memory operations by 7-8 ns, which leads to a decrease in performance by SPECInt by 1.5%.
A number of sources claim that AMD provides the ability to enable and disable SEV-ES, and this can be done in an operating system session without rebooting. How does the crypto-security subsystem appear and what levers of influence on it are available to the user?
In Windows Server 2016, the device manager provides information about two sets of devices - the AMD K17 Platform Security Processor 3.0 (Device ID = 1456h) and the AMD Cryptographic Coprocessor (Device ID = 1468h). Since each socket has four processor nodes, a total of eight PSPs and CCPs are detected in the system. The operating system does not report anything about the resources of these processors. It is known, however, that they are connected to the PCI Express bus in full bit mode (x16).
Although PSP / CCP is software-inaccessible, they can be disabled by disabling the device manager. You can even disable the AMD PCI-link leading to them (for PSP, these are buses with ID = 145Ah, for CCP, buses with ID = 1455h), or you can disable the AMD K17 Internal PCIe General Purpose Ports (GPP) bridges. There are 16 of them in the system to provide traffic between the nodes and authorized crypto (co) processors. That, however, does not affect the performance of the platform, judging by the Cinebench R15. The scatter of results in the range of 4700 ... 5100, depending on the phases of the moon, negates the process of collecting metrics.
Actually, Platform Security Processor 3.0 can be disabled by the operating system if it is necessary to save electricity. Here is a dumb question in the eyes: can one do this?
AMD initiatives on hardware protection of user data will not be needed until Microsoft, Oracle, Red Hat and VMware support them with software products. Encryption can be useful on the same day when the appropriate software becomes available. Otherwise, it will all look like a story with 3DNow!
The ASUS KNPP-D3 server board with dual AMD EPYC 7551 processors in the RS700A-E9-RS4 package supports a set of proprietary encryption technology from Advanced Micro Devices
When the opportunity arose for us to explore the ASUS KNPP-D32 motherboard with two EPYC 7551s, the challenge was to determine the features of crypto protection implemented there. Not least because it is difficult to imagine a different use of such a platform, except in the form of a hostel for virtual machines. All this farm, packed in a 1U rack-mount case with a terabyte of memory of 64 processor cores, is a good illustration of the high proportion of computational capabilities. (When sparing mode of power consumption, by the way).
Protection of user data is seen in AMD as a triple task consisting of memory encryption ( Secure Memory Encryption ), virtual encryption ( Secure Encrypted Virtualization) and processor context encryption (Encrypted State). The second volume of the “ AMD64 Architecture Programmer's Manual ” reports that you can find out if the platform is ready by running the CPUID instruction. Its 8000001Fh function in the EAX, EBX, ECX and EDX registers gives a complete picture of the state of cryptographic protection. Let's use the JavaCrossPlatformCPUID utility.
Although we do not find the desired function among the bookmarks, the result of its work can be seen in the dump - the EAX register contains 0000000Fh. Page 534 of the above document suggests that all security modes on the ASUS RS700A-E9 platform are normal.
However, you can not go into details. AIDA64 reports the same result. True, information about support for the Secure Memory Encryption mode is for some reason not available to users of this program — another argument in favor of direct diagnostics via the CPUID functions.
Now, cloud services are simply obliged to guarantee the residents of the communal apartment that their virtual machines are completely isolated from each other, as well as from the inquiring eye of the host platform. By the way, optimists may not encrypt their guest tasks: along with encrypted virtual peacekeepers, unencrypted virtual machines also coexist (until now, they didn’t have to choose - you had to be “like everyone else”: either or).
Things are going to be easy - to assess the overhead of encryption: regardless of the processor performance, encryption algorithms have always created and continue to create sensitive overheads. The site techpowerup , referring to AMD, claims about an increase in the delay in memory operations by 7-8 ns, which leads to a decrease in performance by SPECInt by 1.5%.
A number of sources claim that AMD provides the ability to enable and disable SEV-ES, and this can be done in an operating system session without rebooting. How does the crypto-security subsystem appear and what levers of influence on it are available to the user?
In Windows Server 2016, the device manager provides information about two sets of devices - the AMD K17 Platform Security Processor 3.0 (Device ID = 1456h) and the AMD Cryptographic Coprocessor (Device ID = 1468h). Since each socket has four processor nodes, a total of eight PSPs and CCPs are detected in the system. The operating system does not report anything about the resources of these processors. It is known, however, that they are connected to the PCI Express bus in full bit mode (x16).
Although PSP / CCP is software-inaccessible, they can be disabled by disabling the device manager. You can even disable the AMD PCI-link leading to them (for PSP, these are buses with ID = 145Ah, for CCP, buses with ID = 1455h), or you can disable the AMD K17 Internal PCIe General Purpose Ports (GPP) bridges. There are 16 of them in the system to provide traffic between the nodes and authorized crypto (co) processors. That, however, does not affect the performance of the platform, judging by the Cinebench R15. The scatter of results in the range of 4700 ... 5100, depending on the phases of the moon, negates the process of collecting metrics.
Actually, Platform Security Processor 3.0 can be disabled by the operating system if it is necessary to save electricity. Here is a dumb question in the eyes: can one do this?
Conclusion
AMD initiatives on hardware protection of user data will not be needed until Microsoft, Oracle, Red Hat and VMware support them with software products. Encryption can be useful on the same day when the appropriate software becomes available. Otherwise, it will all look like a story with 3DNow!
All Articles