On 24.04.20 18:27, Paolo Bonzini wrote:
On 24/04/20 14:56, Alexander Graf wrote:
Yes, that part is not documented in the patch set, correct. I would
personally just make an example user space binary the documentation for
now. Later we will publish a proper device specification outside of the
Linux ecosystem which will describe the register layout and image
loading semantics in verbatim, so that other OSs can implement the
driver too.
But this is not part of the device specification, it's part of the child
enclave view. And in my opinion, understanding the way the child
enclave is programmed is very important to understand if Linux should at
all support this new device.
Oh, absolutely. All of the "how do I load an enclave image, run it and
interact with it" bits need to be explained.
What I was saying above is that maybe code is easier to transfer that
than a .txt file that gets lost somewhere in the Documentation directory :).
I'm more than happy to hear of other suggestions though.
To answer the question though, the target file is in a newly invented
file format called "EIF" and it needs to be loaded at offset 0x800000 of
the address space donated to the enclave.
What is this EIF?
It's just a very dumb container format that has a trivial header, a
section with the bzImage and one to many sections of initramfs.
As mentioned earlier in this thread, it really is just "-kernel" and
"-initrd", packed into a single binary for transmission to the host.
* a new Linux kernel format? If so, are there patches in flight to
compile Linux in this new format (and I would be surprised if they were
accepted, since we already have PVH as a standard way to boot
uncompressed Linux kernels)?
* a userspace binary (the CPL3 that Andra was referring to)? In that
case what is the rationale to prefer it over a statically linked ELF binary?
* something completely different like WebAssembly?
Again, I cannot provide a sensible review without explaining how to use
all this. I understand that Amazon needs to do part of the design
behind closed doors, but this seems to have the resulted in issues that
reminds me of Intel's SGX misadventures. If Amazon has designed NE in a
way that is incompatible with open standards, it's up to Amazon to fix
Oh, if there's anything that conflicts with open standards here, I would
love to hear it immediately. I do not believe in security by obscurity :).
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