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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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.




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux