[svsm-devel] Notes: SVSM Call 2023-09-13

[Oliver Steffen]

Hi all,
I tried to capture the conversation during the meeting as best I
could. But it definitely has some holes, sorry. We talked about a lot of
things during this 1h.

Please feel free to comment, correct, and extend where necessary.

---

Recording of the meeting was not possible due to technical reasons.

The introduction round was skipped due to the number of participants
(>20).

Agenda:

- Jörg: Goal of this call is to raise awareness in the community on who
  is doing what and to sync on plans and wishes for the project.

Development update from SUSE:
  - Work on CPL3 support ongoing
    Jörg showed a diagram of the virtual memory management data
    structures.

   @Jörg, can you describe it again here? I was not able to correctly
     capture this during the meeting. Also please attach the diagram :-)

Crypto support

  - Claudio's PR uses the RustCrypto crate, which is fine for now.
     Later, we need something different to get certification.
  - Jörg: We could create a separate crypto module, that could be in C,
    and make use of well established libraries
  - Claudio: could be a good idea, but this needs more infrastructure
    for exchanging data between the modules, etc.
  - James: IPC vs library based approach, IPC might have architectural
    problems if used in a kernel (as the SVSM is)
  - Jörg: OTOH, including crypto lib into each module requires
    certification for each module. We should look at the performance
    impact of IPC, see if it is feasible.
    We could use shared memory between tasks.
  - Nicolai: We might need an object file for FIPS certification,
    a static Rust crate might not be sufficient.
  - Jörg: We would need a userspace library linker
  - James: Look at the a.out format.
  - Carlos: Separate libraries would also help with fuzzing.

  The discussion is to be continued on the mailing list.

Launch protocol

  Jörg talked about the IGVM file format from Microsoft
  (https://github.com/microsoft/igvm)
  - It is a hypervisor independent description of a CVM
  - usable for both AMD SEV-SNP and Intel TDX
  - It is under MIT license
  - Comes with a Rust crate (for use on the hypervisor side)
  - This could be a replacement for the current launch protocol
  - With this we could get rid of the stage2 loader
  - Would not have to touch Qemu's fw_cfg mechanism in Coconut
  - The implementation on the Qemu side is still missing.
  - The question is, will this be adopted widely?
  - It might become a maintenance burden if nobody else is using it.
  - OVMF also needs to adopt it.

Priorities of features

 - Jörg:
    - CPL3 has highest priority
    - it is hard to parallelize this work across people
    - but other features can be developed in parallel
 - Jörg was asked to share diagrams or description of the intended CPL3
   design, so the community can discuss in parallel.
 - Would it help to implement a simplified CPL3 support as a first step?
   So that work on dependent parts (vTPM module, for example) can start
   sooner?

Governance

  - Jörg: From face to face discussions at KVM forum:
    - A model of 3 top-level maintainers from different entities.
    - But how to choose?
  - Candidates should have a significant track record in the project
    (code contribution and/or reviews)
  - Which entities are to consider?
  - Claudio volunteered to look after the vTPM implementation, but so
    far no other candidates.
  - Currently approx. 14 contributions according to GitHub, many have
    very few commits.
  - Maybe we should wait some more time and see who is active in the
    project?

The call ended abruptly due to the time limit of 1h imposed by gmeet.


Oliver