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? > 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. Paolo > 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.
