On Wed, 9 Feb 2022 at 14:50, Alexander Graf <graf@xxxxxxxxxx> wrote: > On 28.01.22 16:47, Stefan Hajnoczi wrote: > > Dear QEMU, KVM, and rust-vmm communities, > > QEMU will apply for Google Summer of Code 2022 > > (https://summerofcode.withgoogle.com/) and has been accepted into > > Outreachy May-August 2022 (https://www.outreachy.org/). You can now > > submit internship project ideas for QEMU, KVM, and rust-vmm! > > > > If you have experience contributing to QEMU, KVM, or rust-vmm you can > > be a mentor. It's a great way to give back and you get to work with > > people who are just starting out in open source. > > > > Please reply to this email by February 21st with your project ideas. > > > > Good project ideas are suitable for remote work by a competent > > programmer who is not yet familiar with the codebase. In > > addition, they are: > > - Well-defined - the scope is clear > > - Self-contained - there are few dependencies > > - Uncontroversial - they are acceptable to the community > > - Incremental - they produce deliverables along the way > > > > Feel free to post ideas even if you are unable to mentor the project. > > It doesn't hurt to share the idea! > > > I have one that I'd absolutely *love* to see but not gotten around > implementing myself yet :) > > > Summary: > > Implement -M nitro-enclave 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. > > Links: > > https://aws.amazon.com/ec2/nitro/nitro-enclaves/ > https://lore.kernel.org/lkml/20200921121732.44291-10-andraprs@xxxxxxxxxx/T/ > > Details: > > Skill level: intermediate - advanced (some understanding of QEMU machine > modeling would be good) > Language: C > Mentor: Maybe me (Alexander Graf), depends on timelines and holiday > season. Let's find an intern first - I promise to find a mentor then :) > Suggested by: Alexander Graf > > > Note: I don't know enough about rust-vmm's debugging capabilities. If it > has gdbstub and a local UART that's easily usable, the project might be > perfectly viable under its umbrella as well - written in Rust then of > course. It would be great to have an open source Enclave environment for development and testing in QEMU. Could you add a little more detail about the tasks involved. Something along the lines of: - Implement a device model for the TPM device (link to spec or driver code below) - Implement vsock device (or is this virtio-mmio vsock?) - Add a test for the TPM device - Add an acceptance test that boots a minimal EIF payload This will give candidates more keywords and links to research this project. Thanks, Stefan
