Re: [PATCH v1 00/15] Add support for Nitro Enclaves

[Liran Alon]

On 23/04/2020 16:19, Paraschiv, Andra-Irina wrote:
> The memory and CPUs are carved out of the primary VM, they are 
> dedicated for the enclave. The Nitro hypervisor running on the host 
> ensures memory and CPU isolation between the primary VM and the 
> enclave VM.
I hope you properly take into consideration Hyper-Threading speculative 
side-channel vulnerabilities here.
i.e. Usually cloud providers designate each CPU core to be assigned to 
run only vCPUs of specific guest. To avoid sharing a single CPU core 
between multiple guests.
To handle this properly, you need to use some kind of core-scheduling 
mechanism (Such that each CPU core either runs only vCPUs of enclave or 
only vCPUs of primary VM at any given point in time).

In addition, can you elaborate more on how the enclave memory is carved 
out of the primary VM?
Does this involve performing a memory hot-unplug operation from primary 
VM or just unmap enclave-assigned guest physical pages from primary VM's 
SLAT (EPT/NPT) and map them now only in enclave's SLAT?

> Let me know if further clarifications are needed.
I don't quite understand why Enclave VM needs to be provisioned/teardown 
during primary VM's runtime.

For example, an alternative could have been to just provision both 
primary VM and Enclave VM on primary VM startup.
Then, wait for primary VM to setup a communication channel with Enclave 
VM (E.g. via virtio-vsock).
Then, primary VM is free to request Enclave VM to perform various tasks 
when required on the isolated environment.

Such setup will mimic a common Enclave setup. Such as Microsoft Windows 
VBS EPT-based Enclaves (That all runs on VTL1). It is also similar to 
TEEs running on ARM TrustZone.
i.e. In my alternative proposed solution, the Enclave VM is similar to 
VTL1/TrustZone.
It will also avoid requiring introducing a new PCI device and driver.

-Liran