Internships/ProjectIdeas/QEMUNitroEnclave: Difference between revisions

From QEMU
No edit summary
 
(One intermediate revision by one other user not shown)
Line 1: Line 1:
=== Implement -M nitro-enclave in QEMU  ===
=== Implement -M nitro-enclave in QEMU  ===
   
   
'''Summary:''' AWS EC2 provides the ability to create an isolated sibling VM context from within a VM. This project implements the machine model and input data format parsing needed to run these sibling VMs stand alone in QEMU.
'''Summary:''' AWS EC2 provides the ability to create an isolated sibling VM context from within a VM. This project implements the machine model and input data format parsing needed to run these sibling VMs stand alone in QEMU.


Nitro Enclaves are the first widely adopted implementation of hypervisor assisted compute isolation. Similar to technologies like SGX, it allows to spawn a separate context that is inaccessible by the parent Operating System. This is implemented by "giving up" resources of the parent VM (CPU cores, memory) to the hypervisor which then spawns a second vmm to execute a completely separate virtual machine. That new VM only has a vsock communication channel to the parent and has a built-in lightweight TPM.
Nitro Enclaves are the first widely adopted implementation of hypervisor assisted compute isolation. Similar to technologies like SGX, it allows to spawn a separate context that is inaccessible by the parent Operating System. This is implemented by "giving up" resources of the parent VM (CPU cores, memory) to the hypervisor which then spawns a second vmm to execute a completely separate virtual machine. That new VM only has a vsock communication channel to the parent and has a built-in lightweight TPM.
Line 7: Line 7:
One big challenge with Nitro Enclaves is that due to its roots in security, there are very few debugging / introspection capabilities. That makes OS bringup, debugging and bootstrapping very difficult. Having a local dev&test environment that looks like an Enclave, but is 100% controlled by the developer and introspectable would make life a lot easier for everyone working on them. It also may pave the way to see Nitro Enclaves adopted in VM environments outside of EC2.
One big challenge with Nitro Enclaves is that due to its roots in security, there are very few debugging / introspection capabilities. That makes OS bringup, debugging and bootstrapping very difficult. Having a local dev&test environment that looks like an Enclave, but is 100% controlled by the developer and introspectable would make life a lot easier for everyone working on them. It also may pave the way to see Nitro Enclaves adopted in VM environments outside of EC2.


This project will consist of adding a new machine model to QEMU that mimics a Nitro Enclave environment, including the lightweight TPM, the vsock communication channel and building firmware which loads the special "EIF" file format which contains kernel, initramfs and metadata from a -kernel image.  
This project will consist of adding a new machine model to QEMU that mimics a Nitro Enclave environment, including the lightweight TPM, the vsock communication channel and building firmware which loads the special "EIF" file format which contains kernel, initramfs and metadata from a -kernel image.


'''Tasks:'''
* Implement a device model for the TPM device (link to spec or driver
code below)
* Implement a new machine model
* Implement firmware for the new machine model that implements EIF parsing
* Add tests for the TPM device
* Add integration test for the machine model executing an actual EIF payload
   
   
'''Links:'''
'''Links:'''
* https://aws.amazon.com/ec2/nitro/nitro-enclaves/
* https://aws.amazon.com/ec2/nitro/nitro-enclaves/
* https://lore.kernel.org/lkml/20200921121732.44291-10-andraprs@amazon.com/T/
* https://lore.kernel.org/lkml/20200921121732.44291-10-andraprs@amazon.com/T/
* https://github.com/aws/aws-nitro-enclaves-sdk-bootstrap/blob/main/nsm-driver/nsm.c
   
   
'''Details:'''
'''Details:'''
* Skill level: intermediate - advanced (some understanding of QEMU machine modeling would be good)  
* Skill level: intermediate - advanced (some understanding of QEMU machine modeling would be good)  
* Language: C
* Language: C
* Mentor: tbd, agraf will find a mentor
* Mentor: tbd, agraf will find a mentor
* Suggested by: Alexander Graf (OFTC: agraf, Email: graf@amazon.com)
* Suggested by: Alexander Graf (OFTC: agraf, Email: graf@amazon.com)

Latest revision as of 20:30, 29 March 2022

Implement -M nitro-enclave in QEMU

Summary: AWS EC2 provides the ability to create an isolated sibling VM context from within a VM. This project implements the machine model and input data format parsing needed to run these sibling VMs stand alone in QEMU.

Nitro Enclaves are the first widely adopted implementation of hypervisor assisted compute isolation. Similar to technologies like SGX, it allows to spawn a separate context that is inaccessible by the parent Operating System. This is implemented by "giving up" resources of the parent VM (CPU cores, memory) to the hypervisor which then spawns a second vmm to execute a completely separate virtual machine. That new VM only has a vsock communication channel to the parent and has a built-in lightweight TPM.

One big challenge with Nitro Enclaves is that due to its roots in security, there are very few debugging / introspection capabilities. That makes OS bringup, debugging and bootstrapping very difficult. Having a local dev&test environment that looks like an Enclave, but is 100% controlled by the developer and introspectable would make life a lot easier for everyone working on them. It also may pave the way to see Nitro Enclaves adopted in VM environments outside of EC2.

This project will consist of adding a new machine model to QEMU that mimics a Nitro Enclave environment, including the lightweight TPM, the vsock communication channel and building firmware which loads the special "EIF" file format which contains kernel, initramfs and metadata from a -kernel image.

Tasks:

  • Implement a device model for the TPM device (link to spec or driver

code below)

  • Implement a new machine model
  • Implement firmware for the new machine model that implements EIF parsing
  • Add tests for the TPM device
  • Add integration test for the machine model executing an actual EIF payload

Links:

Details:

  • Skill level: intermediate - advanced (some understanding of QEMU machine modeling would be good)
  • Language: C
  • Mentor: tbd, agraf will find a mentor
  • Suggested by: Alexander Graf (OFTC: agraf, Email: graf@amazon.com)