RE: [RFC PATCH v5 05/26] x86/sgx: Introduce virtual EPC for use by KVM guests

["Huang, Kai" <kai.huang@intel.com>]

> On 2/13/21 5:28 AM, Kai Huang wrote:
> > SGX driver uses misc device /dev/sgx_enclave to support userspace to
> > create enclave.  Each file descriptor from opening /dev/sgx_enclave
> > represents an enclave.
> 
> Is this strictly true?  Does dup(2) create a new enclave?

I don't think dup() will create a new enclave. Enclave data structure is kept in filep->private_data, and only 'open' will create a new one.

> 
> > Unlike SGX driver, KVM doesn't control how guest uses EPC, therefore
> > EPC allocated to KVM guest is not associated to an encalve, and
> > /dev/sgx_enclave is not suitable for allocating EPC for KVM
> 
>   ^ enclave

Ops. Thanks.

> 
> > guest.
> 
> 
> > Having separate device nodes for SGX driver and KVM virtual EPC also
> > allows separate permission control for running host SGX enclaves and
> > KVM SGX guests.
> 
> Specifically, 'sgx_vepc' is a less restrictive interface.  It would make a lot of
> sense to more tightly control access compared to 'sgx_enclave'.

Sean mentioned the opposite is also likely, and I agree. Please see my reply to Sean's.

> 
> > More specifically, to allocate a virtual EPC instance with particular
> > size, the userspace hypervisor opens /dev/sgx_vepc, and uses mmap()
> > with the intended size to get an address range of virtual EPC.  Then
> > it may use the address range to create one KVM memory slot as virtual
> > EPC for guest.
> 
> This paragraph doesn't really explain anything important to me.  Both devices
> require using mmap().

This paragraph was requested by Jarkko to explain how to use this /dev/sgx_vepc. 

Perhaps I can remove it?

Or perhaps I can refine to "To use /dev/sgx_vepc to allocate a virtual EPC instance with particular size, the userspace hypervisor..."?

> 
> With typos in the changelog fixed, I'm OK with the rest:
> 
> Acked-by: Dave Hansen <dave.hansen@intel.com>
> 
> BTW...  A lot of this patch is just a skeletal device driver.  I'm a horrible device
> driver writer, so take this ack as "everything seems explained well" versus "I
> promise this will pass muster with the guys who review device drivers all day
> long."

Thanks.