Hey Stefan!
On 16.03.22 14:16, Stefan Hajnoczi wrote:
On Mon, 14 Feb 2022 at 13:58, Stefan Hajnoczi <stefanha@xxxxxxxxx> wrote:
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:
I must've completely missed your email, sorry :).
- Implement a device model for the TPM device (link to spec or driver
code below)
- Implement vsock device (or is this virtio-mmio vsock?)
Yeah, it's derived from Firecracker. So virtio-mmio for 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.
Hi Alex,
Would you like me to add this project idea to the list? Please see
what I wrote above about adding details about the tasks involved.
Petre literally pointed me to the fact that the project did not end up
on the wiki page a few hours ago. I added it and augmented the bits
above. Please let me know if you see anything else missing! :)
Alex
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879