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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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






[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux