On 25/04/2020 19:05, Paolo Bonzini wrote:
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
On 24/04/20 21:11, Alexander Graf wrote:
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
:).
whynotboth.jpg :D
:) Alright, I added it to the list, in addition to the sample we've been
talking before, with the basic flow of the ioctl interface usage.
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.
Okay, got it. So, correct me if this is wrong, the information that is
needed to boot the enclave is:
* the kernel, in bzImage format
* the initrd
* a consecutive amount of memory, to be mapped with
KVM_SET_USER_MEMORY_REGION
Yes, the kernel bzImage, the kernel command line, the ramdisk(s) are
part of the Enclave Image Format (EIF); plus an EIF header including
metadata such as magic number, eif version, image size and CRC.
Off list, Alex and I discussed having a struct that points to kernel and
initrd off enclave memory, and have the driver build EIF at the
appropriate point in enclave memory (the 8 MiB ofset that you mentioned).
This however has two disadvantages:
1) having the kernel and initrd loaded by the parent VM in enclave
memory has the advantage that you save memory outside the enclave memory
for something that is only needed inside the enclave
Here you wanted to say disadvantage? :) Wrt saving memory, it's about
additional memory from the parent / primary VM needed for handling the
enclave image sections (such as the kernel, ramdisk) and setting the EIF
at a certain offset in enclave memory?
2) it is less extensible (what if you want to use PVH in the future for
example) and puts in the driver policy that should be in userspace.
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.
If you want to keep EIF, we measured in QEMU that there is no measurable
difference between loading the kernel in the host and doing it in the
guest, so Amazon could provide an EIF loader stub at 0xfffffff0 for
backwards compatibility.
Thanks for info.
Andra
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 :).
That's great to hear!
Paolo
Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005.
