Hi, I just noticed the reference URL for number [4] in my cover-letter is incorrect.
On Sat, May 18, 2024 at 2:08 PM Dorjoy Chowdhury <dorjoychy...@gmail.com> wrote: > > Hi, > > Hope everyone is doing well. I am working on adding AWS Nitro Enclave[1] > emulation support in QEMU. Alexander Graf is mentoring me on this work. This > is > a patch series adding, not yet complete, but useful emulation support of nitro > enclaves. I have a gitlab branch where you can view the patches in the gitlab > web UI for each commit: > https://gitlab.com/dorjoy03/qemu/-/tree/nitro-enclave-emulation > > AWS nitro enclaves is an Amazon EC2[2] feature that allows creating isolated > execution environments, called enclaves, from Amazon EC2 instances, which are > used for processing highly sensitive data. Enclaves have no persistent storage > and no external networking. The enclave VMs are based on Firecracker microvm > and have a vhost-vsock device for communication with the parent EC2 instance > that spawned it and a Nitro Secure Module (NSM) device for cryptographic > attestation. The parent instance VM always has CID 3 while the enclave VM gets > a dynamic CID. The enclave VMs can communicate with the parent instance over > various ports to CID 3, for example, the init process inside an enclave sends > a > heartbeat to port 9000 upon boot, expecting a heartbeat reply, letting the > parent instance know that the enclave VM has successfully booted. > > From inside an EC2 instance, nitro-cli[3] is used to spawn an enclave VM using > an EIF (Enclave Image Format)[4] file. EIF files can be built using nitro-cli > as well. There is no official EIF specification apart from the github > aws-nitro-enclaves-image-format repository[4]. An EIF file contains the > kernel, > cmdline and ramdisk(s) in different sections which are used to boot the > enclave > VM. You can look at the structs in hw/i386/eif.c file for more details about > the EIF file format. > > Adding nitro enclave emulation support in QEMU will make the life of AWS Nitro > Enclave users easier as they will be able to test their EIF images locally > without having to run real nitro enclaves which can be difficult for debugging > due to its roots in security. This will also make quick prototyping easier. > > In QEMU, the new nitro-enclave machine type is implemented based on the > microvm > machine type similar to how AWS Nitro Enclaves are based on Firecracker > microvm. > The vhost-vsock device support is already part of this patch series so that > the > enclave VM can communicate to CID 3 using vsock. A mandatory 'guest-cid' > machine type option is needed which becomes the CID of the enclave VM. Some > documentation for the new 'nitro-enclave' machine type has also been added. > The > NSM device support will be added in the future. > > The plan is to eventually make the nitro enclave emulation in QEMU standalone > i.e., without needing to run another VM with CID 3 with proper vsock > communication support. For this to work, one approach could be to teach the > vhost-vsock driver in kernel to forward CID 3 messages to another CID > (set to CID 2 for host) so that users of the nitro-enclave machine type can > run the necessary vsock server/clients in the host machine (some defaults can > be implemented in QEMU as well, for example, sending a reply to the heartbeat) > which will rid them of the cumbersome way of running another whole VM with CID > 3. This way, users of nitro-enclave machine in QEMU, could potentially also > run > multiple enclaves with their messages for CID 3 forwarded to different CIDs > which, in QEMU side, could then be specified using a new machine type option > (parent-cid) if implemented. I will be posting an email to the linux > virtualization mailing list about this approach asking for feedback and > suggestions soon. > > For local testing you need to generate a hello.eif image by first building > nitro-cli locally[5]. Then you can use nitro-cli to build a hello.eif > image[6]. > > You need to build qemu-system-x86_64 after applying the patches and then you > can run the following command to boot a hello.eif image using the new > 'nitro-enclave' machine type option in QEMU: > > sudo ./qemu-system-x86_64 -M nitro-enclave,guest-cid=8 -kernel > path/to/hello.eif -nographic -m 4G --enable-kvm -cpu host > > The command needs to be run as sudo because for the vhost-vsock device to work > QEMU needs to be able to open vhost device in host. > > Right now, if you just run the nitro-enclave machine, the kernel panics > because > the init process exits abnormally because it cannot connect to port 9000 to > CID > 3 to send its heartbeat message (the connection times out), so another VM with > CID 3 with proper vsock communication support must be run for it to be useful. > But this restriction can be lifted once the approach about forwarding CID 3 > messages is implemented if it gets accepted. > > Thanks. > > Regards, > Dorjoy > > [1] https://docs.aws.amazon.com/enclaves/latest/user/nitro-enclave.html > [2] https://aws.amazon.com/ec2/ > [3] https://docs.aws.amazon.com/enclaves/latest/user/getting-started.html > [4] https://docs.aws.amazon.com/enclaves/latest/user/getting-started.html It should be this instead: [4] https://github.com/aws/aws-nitro-enclaves-image-format Sorry about that. Regards, Dorjoy
