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

Paraschiv, Andra-Irina
2020-04-30T13:59:27Z

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.