Re: [PATCH v1 00/15] Add support for Nitro Enclaves
From: Alexander Graf
Date: Thu Apr 30 2020 - 07:21:22 EST
On 30.04.20 12:34, Paolo Bonzini wrote:
On 28/04/20 17:07, Alexander Graf wrote:
Why don't we build something like the following instead?
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.
Can we add a file format argument and flags to ne_load_image, to avoid
having a v2 ioctl later?
I think flags along should be enough, no? A new format would just be a flag.
That said, any of the commands above should have flags IMHO.
Also, would you consider a mode where ne_load_image is not invoked and
the enclave starts in real mode at 0xffffff0?
Consider, sure. But I don't quite see any big benefit just yet. The
current abstraction level for the booted payloads is much higher. That
allows us to simplify the device model dramatically: There is no need to
create a virtual flash region for example.
In addition, by moving firmware into the trusted base, firmware can
execute validation of the target image. If you make it all flat, how do
you verify whether what you're booting is what you think you're booting?
So in a nutshell, for a PV virtual machine spawning interface, I think
it would make sense to have memory fully owned by the parent. In the
enclave world, I would rather not like to give the parent too much
control over what memory actually means, outside of donating a bucket of it.
Alex
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879