On 25/04/2020 18:25, Liran Alon wrote:
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?
Correct, we take into consideration the HT setup. The enclave gets
dedicated physical cores. The primary VM and the enclave VM don't run on
CPU siblings of a physical core.
Regarding the memory carve out, the logic includes page table entries
handling.
IIRC, memory hot-unplug can be used for the memory blocks that were
previously hot-plugged.
https://www.kernel.org/doc/html/latest/admin-guide/mm/memory-hotplug.html
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.
True, this can be another option, to provision the primary VM and the
enclave VM at launch time.
In the proposed setup, the primary VM starts with the initial allocated
resources (memory, CPUs). The launch path of the enclave VM, as it's
spawned on the same host, is done via the ioctl interface - PCI device -
host hypervisor path. Short-running or long-running enclave can be
bootstrapped during primary VM lifetime. Depending on the use case, a
custom set of resources (memory and CPUs) is set for an enclave and then
given back when the enclave is terminated; these resources can be used
for another enclave spawned later on or the primary VM tasks.
Thanks,
Andra
Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005.