Hi Tom, thanks for that comparision! On Tue, May 02, 2023 at 06:03:55PM -0500, Tom Lendacky wrote: > While both SVSM implementations use the Qemu Firmware Configuration > (fw_cfg) interface, the coconut-svsm relies on it a bit more than > linux-svsm. In either case, other interfaces may need to be supported in > order for an SVSM to work with a VMM other than Qemu. Right, that is something I have been thinking about. After I talked to a few others about it, I came to the conclusion that neither COCONUT nor linux-svsm use an optimal interface to request information from the HV. I think it would be best if we move to a model where the MADT and E820 tables from QEMU (or any other HV) are part of the measured initial memory image, to make that data trusted. But we can discuss that separately. > - Both SVSMs end up located in a memory slot outside of memory that is > reported to the guest. Coconut-svsm gets the location and size from > fwcfg, which is customizable via the Qemu command line. Linux-svsm gets > the location and size from the build process and validates that location > and size. Correct, COCONUT also has a fall-back where it just uses the last 16MB of guest RAM if the fw_cfg file is not there. That needs OVMF support, though. > - Pagetables: > Page table support can be tricky with the x86_64 crate. But in general > I believe it could still be used. Coconut-svsm uses a dynamic offset- > based approach for pagetables based on the final physical address > location. This offset could be utilized in the x86_64 crate > implementation. When CPL3 support comes around, that would require > further investigation. Yeah, COCONUT does not only use an offset mapping, it also has specific mappings for the per-cpu areas. Those are mapped at a fixed location, same with stacks, so the needs already go beyond an offset mapping. > - Coconut-svsm copies the original Secrets Page and the "frees" the memory > for it. I couldn't tell if the memory is zeroed out or not, but > something that should be looked at to ensure the VMPCK0 key is not > leaked. Thanks, that is a real issue. I just wrote a fix for that. > Some questions for coconut-svsm: > - Are there any concerns with using existing code/projects as submodules > within coconut-svsm (e.g. OpenSSL or a software TPM implementation)? > One of our design goals for linux-svsm was desirability to easily > allow downstream users or products to, e.g., use their own crypto > (e.g. company preferred) No concerns from my side to run any code you want in a CPL-3 module. This includes code which uses external libraries such as openssl or libtpm. The modules will be in an archive file packaged with the SVSM binary, so that everything that runs is measured at launch time. > - Are you open to having maintainers outside of SUSE? There is some > linux-svsm community concern about project governance and project > priorities and release schedules. This wouldn't have to be AMD even, > but we'd volunteer to help here if desired, but we'd like to foster a > true community model for governance regardless. We'd love to hear > thoughts on this from coconut-svsm folks. Yes, I am definitely willing to make the project more open and move to a maintainer-group model, no intention from my side to become a BDFL for the project. I just have no clear picture yet how the model should look like and how to get there. I will send a separate email to kick-start a discussion about that. > - On the subject of priorities, the number one priority for the > linux-svsm project has been to quickly achieve production quality vTPM > support. The support for this is being actively worked on by > linux-svsm contributors and we'd want to find fastest path towards > getting that redirected into coconut-svsm (possibly starting with CPL0 > implementation until CPL3 support is available) and the project > hardened for a release. I imagine there will be some competing > priorities from coconut-svsm project currently, so wanted to get this > out on the table from the beginning. That has been under discussion for some time, and honestly I think the approach taken is the main difference between linux-svsm and COCONUT. My position here is, and that comes with a big 'BUT', that I am not fundamentally opposed to having a temporary solution for the TPM until CPL-3 support is at a point where it can run a TPM module. And here come the 'BUT': Since the goal of having one project is to bundle community efforts, I think that the joint efforts are better targeted at getting CPL-3 support to a point where it can run modules. On that side some input and help is needed, especially to define the syscall interface so that it suits the needs of a TPM implementation. It is also not the case that CPL-3 support is out more than a year or so. The RamFS is almost ready, as is the archive file inclusion[1]. We will move to task management next, the goal is still to have basic support ready in 2H2023. [1] https://github.com/coconut-svsm/svsm/pull/27 If there is still a strong desire to have COCONUT with a TPM (running at CPL-0) before CPL-3 support is usable, then I can live with including code for that as a temporary solution. But linking huge amounts of C code (like openssl or a tpm lib) into the SVSM rust binary kind of contradicts the goals which made us using Rust for project in the first place. That is why I only see this as a temporary solution. > Since we don't want to split resources or have competing projects, we are > leaning towards moving our development resources over to the coconut-svsm > project. Great move, much appreciated, thanks a lot for that! Let's work together to make that happen. Regards, -- Jörg Rödel jroedel@xxxxxxx SUSE Software Solutions Germany GmbH Frankenstraße 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
