On 23/04/20 15:19, Paraschiv, Andra-Irina wrote:
2. The enclave itself - a VM running on the same host as the primary VMThanks, this is all useful. However can you please clarify the
that spawned it.
The enclave VM has no persistent storage or network interface attached,
it uses its own memory and CPUs + its virtio-vsock emulated device for
communication with the primary VM.
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.
These two components need to reflect the same state e.g. when the
enclave abstraction process (1) is terminated, the enclave VM (2) is
terminated as well.
With regard to the communication channel, the primary VM has its own
emulated virtio-vsock PCI device. The enclave VM has its own emulated
virtio-vsock device as well. This channel is used, for example, to fetch
data in the enclave and then process it. An application that sets up the
vsock socket and connects or listens, depending on the use case, is then
developed to use this channel; this happens on both ends - primary VM
and enclave VM.
Let me know if further clarifications are needed.
low-level details here?
- the initial CPU state: CPL0 vs. CPL3, initial program counter, etc.
vsock is using eventfd for signalling; wrt enclave VM, it sees the usual interfaces to get interrupts from virtio dev.- the communication channel; does the enclave see the usual local APIC
and IOAPIC interfaces in order to get interrupts from virtio-vsock, and
where is the virtio-vsock device (virtio-mmio I suppose) placed in
memory?
- what the enclave is allowed to do: can it change privilege levels,
what happens if the enclave performs an access to nonexistent memory,
etc.
- whether there are special hypercall interfaces for the enclave
Thanks,
Paolo