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

[Paraschiv, Andra-Irina]

On 29/04/2020 16:20, Paolo Bonzini wrote:
> On 28/04/20 17:07, Alexander Graf wrote:
> > > So why not just start running the enclave at 0xfffffff0 in real mode?
> > > Yes everybody hates it, but that's what OSes are written against.  In
> > > the simplest example, the parent enclave can load bzImage and initrd at
> > > 0x10000 and place firmware tables (MPTable and DMI) somewhere at
> > > 0xf0000; the firmware would just be a few movs to segment registers
> > > followed by a long jmp.
> > There is a bit of initial attestation flow in the enclave, so that
> > you can be sure that the code that is running is actually what you wanted to
> > run.
> Can you explain this, since it's not documented?

Hash values are computed for the entire enclave image (EIF), the kernel 
and ramdisk(s). That's used, for example, to checkthat the enclave image 
that is loaded in the enclave VM is the one that was intended to be run.

These crypto measurements are included in a signed attestation document 
generated by the Nitro Hypervisor and further used to prove the identity 
of the enclave. KMS is an example of service that NE is integrated with 
and that checks the attestation doc.

> >  Â vm = ne_create(vcpus = 4)
> >  Â ne_set_memory(vm, hva, len)
> >  Â ne_load_image(vm, addr, len)
> >  Â ne_start(vm)
> >
> > That way we would get the EIF loading into kernel space. "LOAD_IMAGE"
> > would only be available in the time window between set_memory and start.
> > It basically implements a memcpy(), but it would completely hide the
> > hidden semantics of where an EIF has to go, so future device versions
> > (or even other enclave implementers) could change the logic.
> >
> > I think it also makes sense to just allocate those 4 ioctls from
> > scratch. Paolo, would you still want to "donate" KVM ioctl space in that
> > case?
> Sure, that's not a problem.

Ok, thanks for confirmation. I've updated the ioctl number documentation 
to reflect the ioctl space update, taking into account the previous 
discussion; andnow, given also the proposal above from Alex, the 
discussions we currently have and considering further easy extensibility 
of the user space interface.

Thanks,
Andra

> > Overall, the above should address most of the concerns you raised in
> > this mail, right? It still requires copying, but at least we don't have
> > to keep the copy in kernel space.




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.