The AMD White Paper specific to SEV identifies/reads as:
Its intent is to mitigate malicious activity w/in the Client from bleeding into the Host via very specific attack vectors. It also operates with Hyper-V (MS Product). Awareness of the usage is via a Host Hypervisor API.
While the statement indicates that use of this feature is a "transparent" approach, further reading identifies current technology (Hardware AND Client/Host) must be aware of the activation as ENABLED in the BIOS settings.
In my case, it is with the AMD 1950X platform where the product is installed running the X399 chipset on the ASUS motherboard.
The question(s) then becomes:
Thank you for your guidance and support.
Jim
Quite unlikely it is supported in Workstation 14.x. Looking at the vmware.log of a Ryzen 1700 with Workstation 14.1.1
| vmx| I125: Host AMD-V Capabilities:
| vmx| I125: SVM Revision: 1
| vmx| I125: ASIDs Supported: 32768
| vmx| I125: Nested Paging: yes
| vmx| I125: LBR Virtualization: yes
| vmx| I125: SVM Lock: yes
| vmx| I125: NRIP Save: yes
| vmx| I125: TSC Rate MSR: yes
| vmx| I125: VMCB Clean Bits: yes
| vmx| I125: Flush by ASID: yes
| vmx| I125: Decode Assists: yes
| vmx| I125: Pause Filter: yes
| vmx| I125: Pause Filter Threshold: yes
| vmx| I125: Capability Found: cpuid.SVM = 0x1
| vmx| I125: Capability Found: cpuid.SVM_FLUSH_BY_ASID = 0x1
| vmx| I125: Capability Found: cpuid.SVM_NPT = 0x1
| vmx| I125: Capability Found: cpuid.SVM_DECODE_ASSISTS = 0x1
| vmx| I125: Capability Found: cpuid.SVM_VMCB_CLEAN = 0x1
| vmx| I125: Capability Found: cpuid.SVM_NRIP = 0x1
There is no log entry for MSR C001_0131 which would indicate whether SEV_ES enabled. There is only a reference to MSR C001_114
It seems to also require change at the guest OS level from page 7.
In particular, the guest VM operating system must support handling the new #VC exception and communication with the hypervisor to achieve the emulation support required.
And it looks like it is a feature for EPYC and not Threadripper?
https://www.theregister.co.uk/2016/12/08/amd_virty_encryption_not_quite_there_boffins/
The AMD white paper may be found at:
Recently, AMD introduced the Secure Encrypted Virtualization (SEV) technology [1] that integrates memory encryption with AMD-V virtualization to provide support for encrypted virtual machines (VMs). Encrypted virtual machines are ideal for multi-tenant environments such as cloud computing as they enable protection from a variety of cross-VM and hypervisor-based attacks. For instance, a hypervisor bug which enables a co-resident VM to escape its sandbox and read arbitrary memory on the system cannot be used to steal data or compromise an SEV-enabled VM.
While no security system is 100% secure, SEV significantly reduces the attack surface of VMs in the cloud by encrypting a VM’s memory with a key unique to that VM and unknown to the hypervisor. Many secrets and important information are typically stored in a VM’s memory space and encrypting this content helps prevent attacks and leakage of sensitive data.
However, when secrets are being actively used by the VM they are often resident in CPU registers as well as memory. Whenever a VM stops running, due to an interrupt or other event, its register contents are saved to hypervisor memory and this memory is readable by the hypervisor even if SEV is enabled. This information could allow a malicious or compromised hypervisor to steal information or alter critical values in guest state such as an instruction pointer, encryption key, etc.
The new SEV with Encrypted State (SEV-ES) feature blocks attacks like these by encrypting and protecting all CPU register contents when a VM stops running. This prevents the leakage of information in CPU registers to components like the hypervisor, and can even detect and prevent malicious modifications to CPU register state. SEV-ES builds upon SEV to provide an even smaller attack surface and additional protection for a guest VM from the hypervisor.
This document presents a technical overview of the SEV-ES feature, the principles behind the architecture, and protections offered to further isolate encrypted VMs. For additional technical details, please see the AMD64 Programmer’s Manual [2].
Quite unlikely it is supported in Workstation 14.x. Looking at the vmware.log of a Ryzen 1700 with Workstation 14.1.1
| vmx| I125: Host AMD-V Capabilities:
| vmx| I125: SVM Revision: 1
| vmx| I125: ASIDs Supported: 32768
| vmx| I125: Nested Paging: yes
| vmx| I125: LBR Virtualization: yes
| vmx| I125: SVM Lock: yes
| vmx| I125: NRIP Save: yes
| vmx| I125: TSC Rate MSR: yes
| vmx| I125: VMCB Clean Bits: yes
| vmx| I125: Flush by ASID: yes
| vmx| I125: Decode Assists: yes
| vmx| I125: Pause Filter: yes
| vmx| I125: Pause Filter Threshold: yes
| vmx| I125: Capability Found: cpuid.SVM = 0x1
| vmx| I125: Capability Found: cpuid.SVM_FLUSH_BY_ASID = 0x1
| vmx| I125: Capability Found: cpuid.SVM_NPT = 0x1
| vmx| I125: Capability Found: cpuid.SVM_DECODE_ASSISTS = 0x1
| vmx| I125: Capability Found: cpuid.SVM_VMCB_CLEAN = 0x1
| vmx| I125: Capability Found: cpuid.SVM_NRIP = 0x1
There is no log entry for MSR C001_0131 which would indicate whether SEV_ES enabled. There is only a reference to MSR C001_114
It seems to also require change at the guest OS level from page 7.
In particular, the guest VM operating system must support handling the new #VC exception and communication with the hypervisor to achieve the emulation support required.
And it looks like it is a feature for EPYC and not Threadripper?
https://www.theregister.co.uk/2016/12/08/amd_virty_encryption_not_quite_there_boffins/
Based on the findings provided it is precisely what was being sought.
I know that the Threadripper is new enough technology that it shall take a bit of time for the support to permeate the software technology needed to take advantage of the capability.
As to support within the AMD CPU, yes, SEV-ES is fully supported from BIOS > Hardware.
It now remains for those technologies to be put to use by the products that have a need.
I also know that EPYC, as the first Business level platform to be published, also supports the capability and may very well have setup the design model for the Threadripper in that regard.
With today's world ever changing though, the enhanced security is needed and I suspect that the designers for VMWare are hard at work figuring out how best to implement the improvements. Given the footprint of the product though, it is unlikely to be implemented this year (or at the consumer level anyway.)
For me, I have a number of clients that are exploring the deployment of a work-at-home model, and have been reluctant to do so given the nature of their business and the level of confidentiality that needs to be applied. I didn't even know of the capability until a client engineer came to me and it was raised in discussion about support options (should have known though...
)
Thank you for the help and guidance.
As always, I knew there would be a level of response from someone far more knowledgeable than I.
