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

[Paraschiv, Andra-Irina]

On 25/04/2020 19:05, Paolo Bonzini wrote:
> 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.