Re: [Patch v4 1/2] cgroup: svm: Add Encryption ID controller

From: Tom Lendacky
Date: Thu Jan 21 2021 - 18:16:07 EST

On 1/21/21 9:55 AM, Tejun Heo wrote:

On Thu, Jan 21, 2021 at 08:55:07AM -0600, Tom Lendacky wrote:
The hardware will allow any SEV capable ASID to be run as SEV-ES, however,
the SEV firmware will not allow the activation of an SEV-ES VM to be
assigned to an ASID greater than or equal to the SEV minimum ASID value. The
reason for the latter is to prevent an !SEV-ES ASID starting out as an
SEV-ES guest and then disabling the SEV-ES VMCB bit that is used by VMRUN.
This would result in the downgrading of the security of the VM without the
VM realizing it.

As a result, you have a range of ASIDs that can only run SEV-ES VMs and a
range of ASIDs that can only run SEV VMs.

I see. That makes sense. What's the downside of SEV-ES compared to SEV w/o
ES? Are there noticeable performance / feature penalties or is the split
mostly for backward compatibility?

SEV-ES is an incremental enhancement of SEV where the register state of the guest is protected/encrypted. As with a lot of performance questions, the answer is depends. With SEV-ES, there is additional overhead associated with a world switch (VMRUN/VMEXIT) to restore and save additional register state. Also, exit events are now divided up into automatic exits (AE) and non-automatic exits (NAE). NAE events result in a new #VC exception being generated where the guest is then required to use the VMGEXIT instruction to communicate only the state necessary to perform the operation. A CPUID instruction is a good example, where a shared page is used to communicate required state to the hypervisor to perform the CPUID emulation, which then returns the results back through the shared page to the guest. So it all depends on how often the workload in question performs operations that result in a VMEXIT of the vCPU, etc.