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.
